Skip to main content

Auto-Discovery System - Hitachi ID Access Certifier

Hitachi ID Access Certifier is used to review and certify or clean up actual user entitlements, based on data periodically extracted from integrated systems and applications. It uses "live feeds" rather than static "CSV files".

Auto-Discovery Infrastructure

Access Certifier 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 Access Certifier 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 always 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 Access Certifier is extracted.
  • Connections to target systems are made in a massively multi-threaded fashion, to minimize runtime.

The list operation in all Access Certifier connectors writes list files to the filesystem of the relevant Access Certifier server. Once all list files have been generated, a separate process determines what changed in each list file and loads appropriate updates into the Access Certifier database schema. 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 Access Certifier 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 to run, in smaller deployments, to 2--3 hours to run, in large enterprises with tens of thousands of users and hundreds of integrated systems.

Building User Profiles

Access Certifier extracts a list of login IDs from each target system, at least every 24 hours. This process is fail-safe; where account lists extracted from a target system fail to return sufficient data, they are discarded and the previously-harvested account list is retained.

Some target systems are designated by customers as sources of user profiles. Every user ID that appears in one or another source of profile system is assigned a user profile in Access Certifier, if one did not already exist. Existing user profiles that no longer appear on any of these authoritative systems are automatically deactivated.

Login IDs on systems that are identified as having a consistent naming scheme are automatically attached to Access Certifier 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 enroll 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 invited too frequently and that the number of users asked to enroll on any given day is limited. 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 enroll, 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.

By default, user profile data is stored in the Access Certifier database, which is replicated among Access Certifier 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.

Excluding Users

User objects that are not intended to be managed by Access Certifier 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:

  1. By identifying them individually:

    Access Certifier administrators can add users IDs to a table which enumerates users who, should they appear on target systems, should not be included in Access Certifier.

  2. Using exclude and include files:

    Access Certifier administrators can create files in the Access Certifier 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.

  3. Using group memberships and organizational units:

    Access Certifier 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 Access Certifier to be used to manage users in one part of a directory and not another.

  4. Using scripts:

    Access Certifier 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

Access Certifier 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 Access Certifier identity cache, so that the various Access Certifier 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 Access Certifier.

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 Access Certifier.

Read More:

  • Architecture:
    Hitachi ID Suite network architecture.
  • Included Connectors:
    Systems on which Access Certifier can audit and reduce privileges.
  • Auto-Discovery System:
    How the Hitachi ID Access Certifier automatically discovers new, deleted and changed users and privileges on integrated systems and applications.
  • Other Integrations:
    Integrations between Hitachi ID Suite and other parts of an IT infrastructure.
  • Workflow:
    Workflow to prompt stakeholders to perform micro-audits, and to authorize access reductions.
  • RBAC:
    Relating Access Certification to role based access control.
  • Server Requirements:
    Sizing, configuration and number of servers on which to deploy Access Certifier
  • Language Support:
    Languages Supported by the Hitachi ID Identity and Access Management Suite
page top page top