User provisioning-best-practices

User Provisioning Best Practices

© 2009 Hitachi ID Systems, Inc. All rights reserved.

http://Hitachi.com/

http://Hitachi-ID.com/

Contents

1 Introduction 1

2 Background 2

2.1 Enterprise Identity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.2 Lifecycle Management and Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3 Business Drivers for Enterprise Identity Management 6

3.1 Cost Containment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.1.1 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.1.2 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.2 Security Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2.1 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2.2 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.3 Regulatory Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.3.1 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.3.2 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4 Human Factors 11

5 Enforcing Standards 12

5.1 Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5.1.1 Login ID Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5.1.2 Change Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

6 Administration Processes 15

6.1 Automated Change Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

6.1.1 When to use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

6.1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

6.1.3 How to use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

6.1.4 Pitfalls to avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6.2 Self service workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6.2.1 When to use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

6.2.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

i

6.2.3 How to use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20


6.3 Consolidated user administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6.3.1 When to use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6.3.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6.3.3 How to use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23


6.4 Delegated user administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

6.4.1 When to use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

6.4.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

6.4.3 How to use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24


7 Internal Controls 26

8 Summary 28

© 2009 Hitachi ID Systems, Inc. All rights reserved.

http://Hitachi.com/


1 Introduction

This document describes and justifies current user provisioning best practices in an enterprise network. Itis intended to offer reasoned guidance to information technology decision makers when they set securitypolicy and design processes to manage user identity data, such as accounts and directory objects, acrossmultiple enterprise systems.

The document is organized as follows:

• Background information:

Defining enterprise identity management and identifying business drivers for and deliverables fromuser life-cycle management.

• Business drivers:

Including both hard and soft costs, security threats and regulatory compliance.

• Human factors:

How human behaviour affects identity management outcomes.

• Administration processes:

Recommended business processes for managing user identity data and user access to systems.

• Internal controls:

Requirements and recommendations for establishing effective internal controls over user access tosystems.

• Find out more:

Other resources with information about password management.

Look for the marks in the margin of this document to find best practices.

© 2009 Hitachi ID Systems, Inc. All rights reserved. 1


2 Background

2.1 Enterprise Identity Management

Enterprise Identity and Access Management (IDM) is defined as a set of processes and technologies tomore effectively and consistently manage user objects for modest numbers of users (under 1 million) overrelatively large numbers of systems and directories (at least 5 and possibly thousands of separate userdatabases).

Typical Enterprise Identity and Access Management applications include:

• Password synchronization and reset.

• User provisioning: self-service workflow, consolidated administration and delegated administration ofusers across multiple systems.

• Meta directory: automated synchronization of user profile data between systems.

• Consolidated reporting, audit and regulatory compliance.

• Single sign-on into legacy applications.

• Web single sign-on and web application access management.

Enterprise Identity and Access Management presents different challenges than identity and access man-agement in Extranet (B2C or B2B) environments:

Characteristic Enterprise IDM Extranet IDM

Number of users under 1 million over 1 million

Number of systems anddirectories

2 – 10,000 1 – 2

Legacy users Thousands of existing users Frequently all-new users

Login ID reconciliation Existing user objects on differentsystems are often unconnectedand share no “anchor” attributes.

Single object per user or aconsistent object namingsystem.

Data quality Lots of orphan and dormantusers. Data unsynchronizedbetween multiple objectsbelonging to the same user.

Single or few objects per user,so no synchronization problems.Orphan and dormant problemssometimes also apply.

Modeling complexity Large numbers of unique users. Modest number of roles. Most orall users belong to just one roleand each role has thousands ofmembers.

In short, Enterprise IDM has fewer but more complex users. Extranet IDM has many users and highertransaction rates, but users are very regular.



2.2 Lifecycle Management and Access Control

User provisioning is essentially the process that manages a user’s entire lifecycle in regards to access toorganizational IT resources. User life-cycle consists of:

• An onboarding process.• Changes in user profile data, including personal information, access rights and passwords, over time.• A deactivation or de-provisioning process.

Each of these life-cycle processes consists of multiple individual security updates, applied to IT systems,including:

• Enumerate users and groups on the target system.• Create new and delete existing login accounts.• Read and write the identity attributes associated with a user object.• Read and set flags, such as “account enabled/disabled,” “account locked,” and “intruder lockout.”• Change the login ID of an existing account (rename user).• Read a user’s group memberships.• Read a list of a group’s member users.• Add a user to or remove a user from a group.• Create, delete and set the attributes of a group.• Move a user between directory organizational units (OUs).

Most of these IT events are driven by business processes:

• Hiring or contracting.• Changes in roles and responsibilities.• Contract termination or end of employment.

Some of these IT events are driven by IT infrastructure requirements:

• Password expiry.• System upgrades and migrations.• Setup of new applications, teardown of old ones.

Traditionally, the connection between business processes and IT security administration events has beenweak and unreliable. It is often a manual, paper or email based process that is prone to failure or delay.Also, IT administration has been handled separately on each system and application. This complexity isillustrated in Figure 1.

In the figure, there are too many business processes that are individually connected to too many systemsand applications. This creates complexity, cost and delay. Complexity makes IT security updates unreliable.

A preferable infrastructure for managing user life-cycles is illustrated in Figure 2.



Business Processes

Systems and Applications

Users

Passwords

Groups

Attributes

IT Processes

Hire Retire New Application Retire ApplicationResign Finish Contract

ApplicationOperatingSystem

DatabaseDirectory E-mailSystem

ERP LegacyApp

Mainframe

Transfer Fire Start Contract Password Expiry Password Reset

Figure 1: Managing Each Application in its own Silo

Business Processes

Systems and Applications

Users

Passwords

Groups

Attributes

IT Processes

Hire Retire New Application Retire ApplicationResign Finish Contract

ApplicationOperatingSystem

DatabaseDirectory E-mailSystem

ERP LegacyApp

Mainframe

Transfer Fire Start Contract Password Expiry Password Reset

Identity Management System

Figure 2: Managing All Applications Concurrently



In this figure, business processes are connected to a single application, responsible for user administra-tion across the entire IT infrastructure. This identity management application drives individual IT securityadministration events to each system.

This model reduces complexity, which leads to lower cost, shorter delays and better reliability.



3 Business Drivers for Enterprise Identity Management

There are three major business drivers that organizations normally consider when evaluating an identitymanagement project. It is important to understand these drivers when evaluating different identity man-agement solutions and to measure the eventual success of an IdM project. The three business driversare:

• Cost Containment.

• Security Threats.

• Regulatory Compliance.

3.1 Cost Containment

3.1.1 Challenges

Ineffective or manual identity management, such as when user access to each system and application isadministered separately, creates costs:

• Hard cost containment:

Access administration processes are highly redundant. Multiple requests and authorizations are re-quired whenever a user’s needs change. This is followed by multiple tasks for security administrators.Redundant or manual administration is costly for organizations to maintain.

Hard costs are readily measured.

• Soft cost containment:

In many organizations, there is a long delay between the time that new user access needs are needed,and when they are actually provided. This delay causes lost productivity for new hires and for reas-signed users, as they are unable to work until provisioned.

Soft costs are more difficult to measure, but are typically much larger than hard costs.

3.1.2 Solutions

Consolidating and automating the administration of user profile and access data reduces these costs:

• Reduced security administration burden:

Fewer security updates are performed manually, and they are made once per user, rather than onceper user per system. This requires less attention from security administrators, as compared to per-system administration.



• Recovered user productivity:

New users can be provisioned in hours rather than days.

Required changes to user profile or access data can be made immediately using self service, or inhours where authorization is required – again rather than days with manual, per-system processes.

3.2 Security Threats

3.2.1 Challenges

Ineffective identity management, such as when user access to each system and application is administeredseparately, creates the following security problems:

• Orphan accounts:

Without prompt and reliable processes to ensure that access is terminated once users leave an orga-nization, orphan accounts can remain for days, weeks, months or even years after the user in questionis gone.

Unused accounts are an ideal target for intruders, as no-one is likely to notice intruder lockouts andother anomalous behaviour.

• Dormant accounts:

As users change responsibilities, they may no longer require access to some systems, and will stoplogging in. Dormant accounts may persist for years, especially since their owner users remain in theorganization.

Dormant accounts have the same security vulnerabilities as orphan accounts.

• Stale privileges:

As users change responsibilities, they acquire new privileges, and should lose old, unneeded ones,on some systems. Old privileges should be removed when they are no longer needed, to preventboth malicious and accidental intrusions, and to ensure that policies regarding internal controls arecorrectly enforced.

• Unreliable change authorization:

Paper and e-mail based systems cannot guarantee that security changes, such as granting new priv-ileges to users, were performed only after suitable authorization was requested and granted. Asa result, business users may attempt to bypass normal change control processes, especially whenrushed. Under such circumstances, inappropriate security rights may be granted to users, without anyaccountability.

• No accountability:

The default setting on most systems is either not to audit user administration operations (new user,change user, terminate access), or to provide only limited logging. Without detailed and long-term au-diting, it is impossible to determine who granted a privilege to a user, when, and why. This eliminatesany possibility of accountability for system administrators.

• Weak standards enforcement:



Manually created user profiles may be inconsistent, and cannot be guaranteed to comply with policyor corporate standards. As a result, some users may be setup with excessive privileges, some withtoo few, etc.

3.2.2 Solutions

Consolidating and automating the administration of user profile and access data effectively addresses thesesecurity problems:

• Eliminating orphan and dormant accounts:

Reliable, organization-wide processes for access termination eliminate orphan and dormant accounts.

• Identifying and removing stale privileges:

Periodic and network-wide audits of user access rights, made possible by a consolidated user admin-istration system, help managers and application owners to find and remove stale privileges.

• Reliable change authorization:

Changes requested, routed and approved though a security workflow system are guaranteed to haveproper authorization prior to implementation.

• Accountability:

Audit logs maintained in the identity management system create accountability for who updated what,when and why.

• Standards enforcement:

New access setup by the identity management system is guaranteed to comply with contemporarysetup standards.

3.3 Regulatory Compliance

3.3.1 Challenges

Recent legislation in the areas of privacy protection and corporate governance have significantly increasedawareness and compliance requirements for internal controls over data and systems.

Specific requirements common to legislation such as Sarbanes-Oxley, Gramm-Leach-Bliley, HIPAA, FDA21CFR11 and others include:

• Effective authentication when users sign into sensitive systems.

• Effective authorization over user access to sensitive data.

• Effective audit logs of past user access to systems and data, as well as over how users came to haveaccess privileges.



Some legislation, such as Sarbanes-Oxley, raises the bar even further by requiring annual attestation thatinternal controls continue to function and are effective.

These are standard elements of IT security (authentication + authorization + audit = AAA), and most sys-tems and applications have at least some form of AAA. Without consolidated identity management, however,there is no way to bring all the elements of AAA together in an effective manner:

• Authentication:

– Most systems use passwords. User have trouble remembering more than 2 or 3 passwords, sothey write them down.

– Many systems are unable to enforce effective password quality, history and expiry policies. As aresult, users have weak (guessable) passwords.

– When users inevitably forget their passwords or inadvertently trigger a lockout, they call the helpdesk for assistance. Help desk authentication of callers is often weak or non-existent, whichmakes passwords reset by the help desk vulnerable to social engineering attacks.

– High turnover at the help desk, combined with sometimes unreliable access termination pro-cesses, and limited audit trails over password reset processes, leads to ex-staff having the abilityto reset passwords for current users.

• Authorization:

– AAA infrastructure in applications depends on valid and current user profile data. Failure toupdate this data in a timely manner, and to deactivate users when required, means that AAAsystems enforce the right rules for the wrong people.

• Audit:

– AAA systems built into systems and applications do not normally track who created a user, whogranted an authorization, when and why. This information is required to meet regulatory auditrequirements.

3.3.2 Solutions

Effective identity management, that spans multiple systems and applications, supports better administrationof user profile data, which makes AAA systems work as intended:

• Authentication:

– Password synchronization and/or reduced signon reduce the number of passwords that usersmust recall, and help to eliminate written passwords.

– Consolidated password policy enforcement ensures that the few, remaining passwords are se-cure.

– Well engineered password reset processes ensure that users are authenticated reliably prior togetting service to resolve password or intruder lockout problems.



– Delegated password privileges for help desk users ensure that ex-staff do not retain administra-tive privileges.

• Authorization:

– Effective access termination and review processes eliminate stale user access rights, so thatAAA systems can operate on appropriate, current user data.

– A workflow system ensures that all proposed security changes are authorized before being ap-plied to sensitive systems.

• Audit:

– Audit logs maintained in the identity management system create accountability for who updatedwhat, when and why.

– Periodic certification of current user access rights supports mandatory audit of internal controls,stipulated by a variety of regulations.



4 Human Factors

Identity management is all about better administration of information about users: who they are and whatthey can access. Unsurprisingly, this often requires assistance from the users themselves to ensure theirinformation is accurate and complete. Providing a very user friendly system is essential to a successfuldeployment of identity management automation.

Users need to be motivated to use the system, rather than reverting to older, manual processes. From auser’s perspective, it must be easier, more obvious and more rewarding to use the automated provisioningsystem than to call the help desk.

Direct input from many or all users may be required:

• If an enrollment process is required, for example to implement self service login ID reconciliation.

• If a distributed access review process is implemented, whereby all managers review the securityentitlements of their direct subordinates.

• If managers are asked to authorize security change requests made by their subordinates.

• If all new security change requests must be made through the system, and any user who might makesuch a request must be made aware of this.

In these cases, special care must be taken:

• A user awareness program is required, to ensure that all users understand what the system is, whatit is intended to accomplish, where to find it, and how to use it.

• User training may be required. Where large numbers of users are impacted, and in general wherethere may be a significant time lapse between scheduled training and actual use of the system, itis preferable that this be computer-based training (CBT), embedded into the system, rather than in-person education.

• Users need to be automatically reminded to use the system if their input is required.

• Allowance must be made for users who are too busy or simply not available to respond to the system,by supporting delegation of responsibility and automatic escalation from one user to another.

It is sometimes also helpful to implement dis-incentives for inappropriate behaviour. For example, paperforms for access changes may still be accepted, but may be processed significantly more slowly thanautomated requests.

Note that Hitachi ID has a proprietary program, called Hitachi ID Adoption Maximizer (formerly AdMax),to assist organizations with developing appropriate incentive, dis-incentive, education and awareness pro-grams, to maximize user adoption of identity management automation.



5 Enforcing Standards

One of the weaknesses of manual user administration is that people are not consistent, and make mistakes.As a result, human administrators cannot enforce standards over user access definitions with total reliability.

An identity management system can and should enforce standards over change authorization and accesssetup. This includes:

• Naming standards:

– For login IDs.– For placement of users in a structured directory (OU selection).

• Resource allocation:

– For mail / post office server selection and mailbox allocation.– For home directory share, folder and server selection.

• Default security setup:

– Initial group memberships and role memberships on each target system.– Initial security ACL / permission setup on home directories, mail folders and desktop profiles.– Setting of security-related attributes on applications and directories.

• Change authorization

– Ensuring that change requests are submitted by authenticated users, and signed if appropriate.– Ensuring that managers are required to authorize changes.– Ensuring that system/application owners are required to authorize changes.– Requiring signatures to accompany approvals.

• Miscellaneous:

– Default membership in mail distribution lists.– Disk quota allocation.– Tablespace allocation.

5.1 Best Practices

5.1.1 Login ID Assignment

Clearly, the actual policy for each standard will vary from organization to organization. That said, some bestpractices that organizations have found to be effective include:

• Assign users a short login ID, and use that ID on all systems. IDs should be short in order to becompatible with all systems, including legacy. This means a maximum length of 7 or 8 characters, anduse of only letters and digits in login IDs.



• Make login IDs globally unique. Do not assign the same ID to two different users on two differentsystems, or in two different OUs. This makes login ID and event reconciliation easier.

• Don’t reuse IDs. Once an ID has been assigned to a user, it should represent only that user, inperpetuity. This protects the sanctity of audit records.

• Do support longer login IDs, such as full name, SMTP address or fully qualified directory path, butonly as secondary identifiers. Longer IDs may be convenient for users, but do not support effectiveadministration requirements as laid out above.

• Even where a hierarchical namespace is used, maintain a flat namespace for CNs. In other words, noCN should appear twice in a directory, in two different contexts.

• Assign login IDs to people, not positions in the organization. People change roles, but their login IDsshould follow them, to support continuity of communication (e.g., same e-mail address) and account-ability in relation to audit logs.

Many algorithms can be used to assign login IDs in compliance with the above guidelines. Examplesinclude:

• Use the first three digits of the user’s last name, followed by a 5 digit numeric sequence, to create aunique ID.

• Combine the first four letters of the user’s surname, followed by first and second initial, followed bytwo characters to ensure uniqueness.

Ensuring global uniqueness, and preventing reuse, means that a table must be maintained on some systemto track all currently-in-use IDs, IDs that have been reserved but not yet created and IDs that were used inthe past but are not currently active. Such a table is required to prevent ID reuse.

5.1.2 Change Authorization

Requests for security changes normally amount to one or more detailed requests, for one of two things:

• Create a new account for a (new or existing) user.

• Grant a user membership in a security group or security role.

Other, less common types of requests are:

• Access reductions (i.e., deactivate login account and revoke group membership).

• User profile updates (e.g., name change, personal information update).

• Rename ID (e.g., after a name change).

• Temporary enable/disable of access (e.g., holiday, extended leave).



In general, it makes sense to ensure that any requested change is consistent with business requirements,and is appropriate to the operation of the system in question. There should therefore be two types ofauthorizers:

• Managers, that the impacted user either directly or indirectly reports to.

• System, application or resource (e.g., group, role) owners, who have responsibility for the IT assetwhere user privileges or profile information will be updated.

Accordingly, it makes sense for the workflow engine in a user provisioning system to identify both managersand resource owners and invite both to authorize any given request.

Some exceptions to this rule inevitably come up. In particular, executives above a certain level in theorganization may not require managerial approval for their change requests, and due to their position, itwould be pointless to ask for resource owner approval either (it would be granted by default).

Also, a user should not be asked to approve his own change requests – the answer will always be “yes.”This means that the workflow engine must check the list of authorizers prior to sending out invitations, andif the requester was identified as an authorizer, pre-approve that part of the request.

A chronological sequence for authorization must also be considered. In manual systems, authorizers areinvited to review a request one after another – authorization follows the movement of a paper request form.In an automated workflow system, it becomes possible to invite all authorizers at the same time. This isattractive, as it minimizes the total time between request submission and fulfillment. So long as all therequired approvals are provided, there is no security benefit to serializing reviews and approvals (who caresif A approved a request before B, or B before A? Policy usually dictates simply that they both approve. Inother words, parallel authorization is a best practice.

To ensure prompt response, it generally makes sense to ask several candidate authorizers for approval, andtreat a request as approved as soon as some minimum subset of them responds. This creates a race toapprove, whereby the fastest approvers move a request to fulfillment at the earliest possible time. In otherwords, best practice is to ask a group of N resource owners to approve a request, and treat it as approvedonce M respond positively, where M ≤ N .

Supporting multiple, concurrent authorizers leads to a possible situation where some authorizers approve arequest, while others reject it. The simplest resolution for this possibility is to assume that any rejections thatoccur prior to the request being approved act as a veto, and block the request entirely. Once a request hasbeen approved, by the smallest number of authorizers that is considered acceptable, the request should beclosed and all remaining authorizers notified of this fact. This best practice eliminates uncertainty as to thestate of a request, while giving authorizers the right to object to one another’s approvals, so long as theyact in a timely manner.



6 Administration Processes

As mentioned in Subsection 2.2 on Page 3, both business processes and IT requirements drive user ad-ministration events.

In a manual system, there may be different processes for different applications and for different groupsof users, as illustrated in Figure 1 on Page 4. As has already been discussed, this can create securityproblems and is inefficient.

A consolidated user provisioning system, such as that illustrated in Figure 2 on Page 4, is intended to reduceadministration complexity. This is done through implementation of one or more of the following businessprocesses:

• Automation / Change Propagation:Changes to user profiles on authoritative systems (e.g., HR or contractor management) trigger auto-matic updates to the same users’ profiles on managed systems.

• Self service / Workflow:Users or automatic processes submit change requests – to provision new access, change existinguser profiles or deactivate users. Requests are automatically routed to business users with suitableauthority, who approve or reject them. Approved changes are applied to managed systems.

• Consolidation:Security administrators with an enterprise-wide scope of authority update user access to multiplemanaged systems from a single security administration console, that creates a consolidated view ofmultiple security databases.

• Delegation:Regional or departmental security administrators are granted limited access to manage some users,on some systems, through the consolidated security administration console.

• Fulfillment:This is not so much a process as much as it is the ability of one user management system (Hitachi IDIdentity Manager (formerly ID-Synch™)) to implement changes initiated on another system (e.g., apartner’s system), accepted using a web services API.

The following sections describe each process, when and how to use it, and – equally importantly – when itwill not work well.



6.1 Automated Change Propagation

Automated user administration works by monitoring one or more systems of record and waiting for changesto user profile data. Detected changes are then:

1. Filtered, so that only changes within the scope of the system remain.2. Transformed, from the data format of the system of record, to the data format of the identity and

access management system and of the target systems.3. Forwarded, from the identity and access management system to managed systems.

Some examples of auto-provisioning/auto-deactivation are:

1. Payroll staff create a record for a new hire in the HR application. The user provisioning systemdetects this event, notes that it is in scope and reformats the event into workflow requests to create aWindows/AD account, an Exchange mailbox and a mainframe login ID.

2. HR staff set a termination date for an employee in the HR application. The user provisioning systemdetects this and sets the same date in the user’s IDM profile. A batch process runs nightly andautomatically submits “deactivate all accounts” workflow requests for every user whose terminationdate has passed.

3. A rogue administrator adds his accomplice’s login account to the Domain Admins AD group. The userprovisioning system detects this new group membership, removes the user from the group and sendsan SMS message describing what it detected to a security officer.

Authorizers

Systemsof Record

Autodiscovery

IdentitySynchronization

IdentityCache

Invitations,Notifications

Target Systems

WorkflowManager

Transaction Manager

Connectors

Listaccounts

Approve / reject

Create,delete,updateaccountsUpdates

Listpeople

Figure 3: Automatic Propagation of Changes in User Profile Data

6.1.1 When to use

Automatic change propagation is effective if and only if:

• A system of record exists.• That system of record has accurate information about users.



• Updates to user data in the system of record are very timely.

If any one of these conditions can not be met, automated change propagation should not be used.

Where the system of record only relates to certain classes of users, automation will only be effective forthose types of users. For example, where the only reliable and timely system of record is HR, automatedchange propagation will not pertain to contractors, vendors, etc.

Finally, automated change propagation can only be used at the level of granularity of the data available inthe system(s) of record. Referring to the previous example, if the HR application only tracks user names,hire date and termination date, then it will not be possible to assign fine-grained privileges to users basedon data in HR.

6.1.2 Scope

In most organizations, the system of record is the human resources (HR) application. Also in most organi-zations, data in this system is not applicable only to employees and is quite coarse-grained (no informationabout specific security access requirements). Consequently, in such organizations, automatic change prop-agation can only be used to:

• Automatically provision basic systems access to new users. For example, network login IDs, e-mailaccounts and Internet access can be setup for all new employees.

• Automatically deprovision all systems access to terminated users. Regardless of how users came tohave various accounts – when they have left the organization, in most environments, every accessshould be deactivated.

More fine-grained access rights are normally best left to other processes.

6.1.3 How to use

Automation begins with a review of the data quality, timeliness, scope and granularity in the system ofrecord.

Once the type and quality of reference data have been reviewed and accepted, the next step is to identitywhat data changes in the system of record are relevant, and to map those changes to each target system.

Next, a data feed is setup to monitor the system of record, and extract changes.

Finally, transformations are defined, with system of record data as input, and managed system updates asoutput.



6.1.4 Pitfalls to avoid

HR systems and other systems of record frequently include a job code or similar field to represent the user’srole in an organization. This is suggestive of role-based administration, where roles are mapped to privilegesets, and users are provisioned with exhaustive and fine-grained entitlements based on initial and changingjob code in the system of record.

In practice, role engineering is very time consuming and expensive, and is rarely concluded successfully. Asa result, it is best practice to avoid comprehensive role engineering and user classification, at least initially,as this would unduly increase project cost and duration. Instead, focus on simpler operations: creatingbasic user profiles and deactivating access, rather than more fine-grained, role-based automation.



6.2 Self service workflow

A workflow engine allows both business users, in a self-service fashion, and automated processes to re-quest and authorize security changes. This is a key feature of any successful user provisioning system.

Users sign into a secure web application and submit change requests by selecting and filling in a suitableform. Requests are validated by the workflow engine and the requester may be required to make correc-tions.

Some parts of a request may be automatically filled in and may not even be visible to the requester. Forexample, the user provisioning system might automatically assign a standard login ID to all new users,assign a file server and mail server, select a directory OU and so on.

The workflow engine forwards valid requests to one or more authorizers. These are simply other users,chosen through the application of security policy. Example authorizers may include application owners andmanagers in the chain of command above the requester. Some requests may not require authorization atall.

Authorizers are normally prompted to review and either approve or reject security change requests by e-mail. A URL is embedded in the e-mail, which authorizers follow to a secure web application where theysign in, see request details and either approve or reject the request.

The workflow engine must allow for the possibility that authorizers will not respond in a timely manner– by automatically sending reminders, and escalating requests from unresponsive authorizers to otherresponsible users.

The workflow engine must also allow authorizers to actively delegate their responsibility, for example whenthey schedule time off or when they change jobs permanently.

Self-service security administration workflow is illustrated in Figure 4.

Requester

Forminput

Validation /completion

Authorizerrouting

Auto-reminders

Delegatedauthority

Auto-escalation

E-mailnotification

Approved?Approvalform

E-mailinvitations Target Systems

WorkflowManager

Transaction ManagerConnector

Authorizers

Hitachi IDManagement Suite

Figure 4: Self Service Security Administration Workflow



6.2.1 When to use

Self service workflow is effective for knowledge workers, who are comfortable using a computer, and inparticular a web browser, to review current information and request changes.

Self service workflow is not appropriate for populations of users who do not have easy access to a computer,who are not comfortable using one, or who require significant training prior to use of each new application.

6.2.2 Scope

Users, their peers and their managers are the most reliable sources of information about business needfor fine grained access rights. It makes sense to enable users to request specific privileges, such asnew accounts and group memberships. It also makes sense to delegate administration of personal profileinformation – full name, phone number, etc. to users directly.

While automation is frequently a good process for coarse-grained administration of employees, workflow isoften a better choice for other classes of users – contractors, vendors, etc. – for whom a system of recordmay not be available.

6.2.3 How to use

It is reasonable to configure a workflow system as the primary, and often as the sole mechanism by whichusers request new access rights, and update their personal profiles. New access rights may be requestedeither by users or their managers, and should always be authorized by both managers and resource ownersbefore being activated.

Profile updates may be entirely self service (e.g., updating a home phone number or some personal pref-erence information), or may require authorization (e.g., updating a department code, location code or a fullname will typically require HR authorization).

It is essential to make the workflow user interface as simple as possible. Training is pointless, as userswill only access the system infrequently, when they need to request something new, or when they areasked to authorize a change. It is unlikely that users will remember anything from earlier training, monthsafter training was completed, on their first use of the system. Moreover, in-person training is prohibitivelyexpensive, given that most users will probably need to use the system.

To deploy a self service workflow engine, one must address the following design variables:

• Which users will be allowed to make requests.

• Can any user make requests on behalf of any other user? If not, what are the limits relating requestersto recipients?

• Can any user ask for any resource? If not, what are the limits relating requesters to resources?

• What kinds of requests (create/hire? delete/terminate? change?) will any given requester be allowedto make?



• How will each type of request be validated (i.e., syntax validation of input fields, code lookups andconsistency checks).

• Who are appropriate authorizers for each type of request? Typically some combination of managersin the requester’s chain of command plus application owners is used.

• What is the expected response time from authorizers? When should reminders be sent? When shouldrequests be escalated from unresponsive authorizers to alternate, replacement authorizers?

• What parts of a request are authorizers allowed to see? For example, social security numbers andthe like may be part of a request, but not appropriate to display.

• What parts of a request are authorizers allowed to modify? If one authorizer approves a request, anda second authorizer modifies it, this might invalidate the earlier approval.

• Define authorizers in terms of groups, and identify how many of each group must approve a requestbefore it is considered to be ready for fulfillment.


In a realistic enterprise-scale user provisioning deployment, there will be dozens if not hundreds of targetsystems, and dozens to hundreds of types of requests (e.g., create, modify, delete) per target system. Inother words, the total number of transaction types quickly reaches the thousands.

Because of this scale, it is too expensive to define one process per request type. Who will draw thousandsof flow charts? Who will maintain them? To keep the system manageable, it must not require one processdefinition per request type.

Instead, the workflow solution should implement a single, flexible, dynamically-adaptable process, whichlooks up key data such as authorizer identities on the fly. This approach eliminates the need for organi-zations to define hundreds or thousands of their own, supposedly-unique, workflow processes. After all,workflow is used basically for change authorization, and the mechanics of how changes are approved arereally no different from one organization to the next. What does differ between organizations is how changerequests are entered, how the contents of a change request are validated, how authorizers are selected,etc.



6.3 Consolidated user administration

Consolidated user administration allows security officers to manage users across a range of systems froma single console.

Administrators can sign into the consolidated user administration system, access a user’s profile and seemultiple login IDs, attributes and group memberships, as they currently exist on multiple systems, on asingle screen.

Consolidated administration saves time for security administrators, makes it possible to delegate just useradministration rights on platforms where these privileges cannot be natively decoupled from other systemmanagement privileges and supports security functions such as rapid user provisioning and prompt accessdeactivation.

Consolidated user administration is illustrated in Figure 5.

Administrators

Target Systems

Securityadmin UI

IdentityCache

TransactionManager

Connectors

Create,delete,updateaccounts

readcurrentstate

refreshcurrentstate

Figure 5: Consolidated and Delegated User Administration Console

6.3.1 When to use

Consolidated administration makes sense in almost every user provisioning deployment. Inevitably thereare some human security administrators, and it always makes sense to provide them with tools to improveproductivity and simplify access deactivation.

6.3.2 Scope

In most user provisioning system deployments, the first feature to be deployed is consolidated administra-tion, as this makes it possible to test integration with target systems.

Some subset of the following operations is normally supported:

• Enumerate users and groups on the target system.• Create new and delete existing login accounts.• Read and write the identity attributes associated with a user object.• Read and set flags, such as “account enabled/disabled,” “account locked,” and “intruder lockout.”• Change the login ID of an existing account (rename user).• Read a user’s group memberships.• Read a list of a group’s member users.• Add a user to or remove a user from a group.



• Create, delete and set the attributes of a group.• Move a user between directory organizational units (OUs).

In the event that there is no central, global security administration group, consolidated administration shouldstill be enabled, but used purely as a diagnostic tool by administrators of the user provisioning system. In de-centralized organizations, security administrators would only access delegated administration, as describedin Subsection 6.4 on Page 24.

6.3.3 How to use

Consolidated user administration is intended for security officers – i.e., those administrators already taskedwith managing user logins, profiles and access rights across the enterprise.

User security administrators should use the consolidated administration system in place of the pre-existingmix of native administration tools, in order to simplify their work and support improved service.


Consolidated administration systems present a generic view of users, attributes and groups. Sometimes amore platform-specific view is appropriate – for example to manage filesystem privileges, or other attributesthat are simply outside of the scope of the user provisioning system.

To support this requirement, it is normally best to leave native security administration tools in place, andindeed allow the administrators of specific systems and applications (as opposed to enterprise-wide useradministrators) to continue to use the native tools on the systems for which they have responsibility.

In other words, consolidated user administration is designed to supplement native security administrationtools, and to assist in user management. It is not intended to supplant native the security administrationtools that are needed by administrators of individual systems, whose main charge is systems, rather thanusers.



6.4 Delegated user administration

Delegated user administration makes it possible to grant limited security privileges to departmental or re-gional staff. For example, an IT administrator at a business unit may be allowed to create new users in thatbusiness unit, and manage the user profiles and access privileges of local users. The same IT administratorwould be unable to access user profiles for staff working in other business units and may only be able toperform certain types of updates, on certain systems.

Delegated user administration is implemented in the same manner as consolidated user administration, butwith the addition of access controls, as is illustrated in Figure 5.

The scope of authority of a given security administrator can be limited to certain users, certain systems,certain groups or certain OUs. Access controls are normally implemented using business logic, whichaccesses information about both the IT administrator and intended recipients of security changes, to dy-namically determine what kinds of updates are allowed.

6.4.1 When to use

Delegated user administration makes sense in organizations where managers or IT administrators workingat different locations or business units have both the responsibility and expertise to manage users in theirown areas, but not elsewhere in the organization.

6.4.2 Scope

All security transactions, as described in subsubsection 6.3.2 on Page 22, can be supported by a delegatedadministration system.

Where a system or application spans multiple business units or locations, there may be little or no distinctionbetween users that access the same system, but work in different areas.

It is difficult to limit the creation of such users to just those that work in a given business unit, and so itfollows that delegated administrators should not have the right to create users on these systems. They may,however, still have the right to modify or delete users on such systems, so long as the affiliation of theseusers with the appropriate business unit can be automatically determined.

For example, an organization may maintain a global Active Directory system, and attributes on each userobject may specify a department code and location code. Delegated administrators may not be allowedto create new Active Directory users – a task better left to either global security administrators (using aconsolidated user administration console), or to the workflow engine. In the same environment, delegatedadministrators may nonetheless have the right to modify or delete users in their own department or at theirown location.

6.4.3 How to use

The key decisions that a delegated user administration system must make are:



• Does a given user, who attempts to sign into the delegated user administration system, actually havethe right to change the profiles of any other users?

• If so, which users can the delegated administrator view and modify?

• For those users that are within the scope of authority of the delegated administrator, what updates areallowed, and on what systems?

Answers to the above questions form the basis of access controls, which are the core component of dele-gated user administration.

These questions should be answered automatically, drawing on data that already exists, and is alreadymaintained. Any approach that requires creation of new data about who can do what to whom may fail dueto high cost of ownership.

For example, the questions above may be answered as follows:

• Whether a given user is allowed to sign into the delegated user administration system can be deter-mined by examining group membership or an attribute in Active Directory.

• The scope of authority of a delegated IT administrator can be determined by comparing location ordepartment codes, between the administrator and users he wishes to modify.

• The set of target systems that are in scope may be a fixed list for every delegated administrators in agiven department.

In the example, all of the decisions are based on data that is either small and static, or actively maintained,without special regard to the delegated administration system, in a common directory.


Delegated administration is not always appropriate, and is no substitute for workflow.

In many environments, local changes to user security definition require further authorization – e.g., fromapplication owners or upper management. In these cases, delegated administration, which by definition isimmediate, should not be used. Instead, a self service requests workflow should be implemented.



7 Internal Controls

Effective internal controls are an increasingly important component of compliance with both privacy-protectionand corporate governance legislation.

Having effective internal controls is specifically required by many corporate governance and privacy protec-tion laws, and executive management is often required to attest to the efficacy of those controls.

Internal controls in an IT environment normally resolve to three basic features of every system and applica-tion:

• Authentication: to establish the real-world identity of users who initiate login sessions.

• Authorization: to control what a given, authenticated user can see and do.

• Audit: to record those same user actions, and support accountability and forensics at a later date, ifrequired.

Together, these features are commonly referred to as AAA.

Internal controls, or AAA, requires a combination of technology and user data. User data includes: who arethe users, and what should they have access to? How are the logical users on different systems related tosingle, physical users in the real world?

The technology to support AAA is quite mature, having been in use for at least 30 years. Many systemsand applications implement sound authentication, with passwords and other factors; effective authorization,using roles and groups; and extensive audit logs.

The challenge in implementing sound AAA, and therefore establishing effective internal controls, is userdata management. Slow termination leads to orphan accounts. Changes in responsibility lead to staleprivileges. Without sound processes to respond to business changes, and reflect them in AAA data reliablyand promptly, AAA infrastructures correctly enforce the wrong rules, at the wrong time.

Identity management in general, and user provisioning in particular, are ideally suited to addressing thischallenge.

The primary security challenge in maintaining user data is removing privileges in a prompt and reliablemanner. Creating privileges is also important, but has a cost, rather than a security, impact.

Past attempts to leverage user provisioning systems to reliably and promptly terminate access have beenrole based. i.e., change a user’s role, and any old, no-longer-required privileges will be automaticallyreduced. This is appealing in principle, until the complexity of role engineering and policy definition is con-sidered. With those factors in mind, a role-based solution normally becomes unworkable in any deploymentthat exposes even a modest degree of complexity.

Instead of relying on roles and policies, a more pragmatic approach to prompt and reliable access termina-tion, which can actually be deployed in a useful timeframe, is periodic access reviews. An interactive anddistributed access review process is called access certification.



Access certification works as follows:

• The user provisioning system periodically requires managers to review the access rights of their staff.Certification reminders are typically sent by e-mail.

• Managers respond by signing into the user provisioning system.

• The user provisioning system presents managers with a list of their direct subordinates, asking themto identify any staff (user profiles) that no longer work for the organization. These will be removedlater.

• For each remaining, legitimate user, an access profile is displayed, with a list of login accounts andspecific security privileges.

• Managers identify no-longer-needed accounts and privileges and flag them for later removal.

• Managers complete the process above for every direct subordinate, and provide an electronic sig-nature to indicate that they certify that the remaining users, accounts and group memberships areappropriate.

• After a manager completes his review and certification, any proposed changes (removed users, deac-tivated accounts, eliminated group memberships) are bundled into multiple security change requests,and submitted to the the user provisioning workflow engine. These requests will normally require fur-ther authorization, from system owners or higher managers, and will ultimately lead to users, accountsand group memberships being deleted from target systems.

• Certifications are collected up through the organization’s hierarchy. Manager A is unable to completehis own certification until all of his subordinate managers (B, C, ...) have likewise completed theirown certifications. This creates downward pressure through an organization to complete the reviewprocess, and leads to global completion of the certification.



8 Summary

A summary of best practices defined in this document follows:

• Involve your users. Plan for training, education and usability.

• Assign globally-unique, globally compatible login IDs to people (not to jobs), and never reuse IDs.

• Ask both system/application owners and managers to authorize security change requests.

• Perform authorization in parallel, rather than waiting for one stake-holder to approve a request beforeasking the next.

• Assume that some authorizers will not respond on time, so ask more authorizers than are actuallyrequired to approve all changes.

• Avoid large-scale, detailed role engineering. It will either be too costly or impossible to complete.

• Enable self-service for non-critical updates to user profiles. Support staff should not be involved.

• Rather than defining separate business processes for each type of security change request, define asingle, global authorization process, and fill in the details, such as form validation logic and authorizerrouting, for each variation.

• Setup a global user administration console for security officers, to eliminate the use of one-per-systemtools.

• Retain native platform administration tools for specialized tasks. Do not assume that a consolidatedinfrastructure will handle everything.

• Wherever possible, leverage existing, well-maintained data to make delegation and authorization de-cisions.

• Periodically ask all stake-holders to review the security privileges of users within their scope of re-sponsibility, and to flag anomalies for deletion.

www.Hitachi-ID.com

500, 1401 - 1 Street SE, Calgary AB Canada T2G 2J3 Tel: 1.403.233.0740 Fax: 1.403.233.0725 E-Mail: [email protected]

File: /pub/wp/documents/bestpractices/idsynch/bp4.texDate: November 1, 2004

http://Hitachi-ID.com/

Technology

User provisioning-best-practices