Resource Center
Hitachi ID Facebook Page Hitachi ID Twitter Page Find us on Google+ Hitachi ID YouTube Page

Bulk User Creation

A bulk user creation process is one where a list of users and their identity data is loaded into a system or application, rather than interactively creating one user at a time. Typically the user list is provided either as a spreadsheet (i.e., CSV file) or a database table. The data feed may include one row per user, with identity attributes -- name, department, phone number, etc. -- in columns.

It is possible to write scripts to perform bulk user creation tasks for some systems. For example, on Active Directory, the LDIFDE utility can be used to import large numbers of users in an LDIF file. Similar tools are available for other LDAP directories.

Bulk user creation is a special case of the more general automated user administration process.

Hitachi ID Identity Manager can monitor one or more systems of record on a periodic basis (e.g., nightly or every few hours), enumerating new, deleted and changed users. In the case of an HR application, for example, these changes may represent new hires, terminations and transfers. Auto-discovery is performed on all integrated systems and applications -- not just systems of record.

Changes detected by Identity Manager are passed through a data filter, which removes users that are outside Identity Manager's scope. For instance, in a scenario where Identity Manager manages all users in one country, but the HR system is global, Identity Manager would ignore changes to users from other countries.

All changes to a given user are aggregated and business logic is executed, with the set of changes as input. This is best illustrated with some examples:

Detected change

Actions

Net result
New user appears in an HR application.

  • Lookup appropriate role based on the user's location and job code.
  • Submit a change request to the Identity Manager workflow engine, to create a new user, with the HR-provided identity attributes and with resources specified by the role.

Auto-provisioning.
New phone number detected on white pages directory.

  • White pages has a higher priority for the phone number attribute than other systems.
  • Submit a change request to the Identity Manager workflow engine, to change the phone number in the user's profile.
  • Once approved (most likely automatically), the new phone number is mapped to other login IDs belonging to the user and connectors are run to update this information on other systems.

Identity synchronization.
Change to termination date is detected on the HR system.

  • Using the identity synchronization mechanism described above, set this date on the user's profile.
  • A separate batch process periodically identifies users with today or earlier termination dates and submits requests to disable all accounts for every matching user.

Automated termination.
User disappears from system of record (HR).

  • Lookup all of a user's login IDs.
  • Submit a "disable all accounts" change request to the Identity Manager workflow engine.
  • Given the source of the request (employee gone from HR), this type of change may be auto-approved.

Automated termination (2nd method).
User was added to Administrators group on Active Directory domain.

  • Since the change was detected on AD, it follows that it was not initiated by Identity Manager.
  • Submit two change requests to the workflow engine:
    • Remove the user from the Administrators group (this is an auto-approved change).
    • Add the user from the Administrators group (requires approval).
  • Create a security incident in the help desk system.

Detect unauthorized privilege escalation.

 

Collectively, these processes are known as automated user management. They are implemented by the ID-Track component in Identity Manager.

Providing new users with an initial password is a security challenge. Using a default value -- either a constant or something derived from the user's name or profile -- is insecure, because unauthorized users can easily sign in as the new user. Setting the password to a random value and sending it to the user in an e-mail is also problematic: the user may not have an internal e-mail account yet, and external e-mail delivery and hosting services are not secure.

Identity Manager addresses the problem of password initialization as follows:

  • If the account was requested through the Identity Manager request portal then the requester -- who is normally the new user's supervisor -- must specify an initial password in the request. This limits the number of people who know or can intercept the initial password and ensures that someone who will interact closely with the new user provides that password to the new user.

  • If the account was requested by an automated or batch process then the initial password is set to a random value by default. The password can then be reset by or for the user. If it is by the user, he may authenticate by answering questions where the answers were provided in the data feed -- things like driver's license number or date of birth. The user may also sign in using his mobile phone, to which a random PIN may be sent. Alternately, an assisted password reset process may be used, for example where the user's direct manager can reset his password.

  • In every case, new passwords are subjected to stringent complexity rules and are only transmitted over HTTPS.

  • On systems where this is supported, Identity Manager can set new passwords to be expired -- i.e., they must be changed on first use. This shortens the time window during which the initial password is valid.

Return to Identity Management Concepts