User provisioning-best-practices


Published on

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

User provisioning-best-practices

  1. 1. User Provisioning Best Practices © 2009 Hitachi ID Systems, Inc. All rights reserved.
  2. 2. Contents1 Introduction 12 Background 2 2.1 Enterprise Identity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.2 Lifecycle Management and Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Human Factors 115 Enforcing Standards 12 5.1 Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1.1 Login ID Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1.2 Change Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 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
  3. 3. 6.2.3 How to use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.2.4 Pitfalls to avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 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.3.4 Pitfalls to avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 6.4.4 Pitfalls to avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 Internal Controls 268 Summary 28 © 2009 Hitachi ID Systems, Inc. All rights reserved.
  4. 4. User Provisioning Best Practices1 IntroductionThis 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 from user 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 to systems. • 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
  5. 5. User Provisioning Best Practices2 Background2.1 Enterprise Identity ManagementEnterprise 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 of users 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 and 2 – 10,000 1–2 directories Legacy users Thousands of existing users Frequently all-new users Login ID reconciliation Existing user objects on different Single object per user or a systems are often unconnected consistent object naming and share no “anchor” attributes. system. Data quality Lots of orphan and dormant Single or few objects per user, users. Data unsynchronized so no synchronization problems. between multiple objects Orphan and dormant problems belonging to the same user. sometimes also apply. Modeling complexity Large numbers of unique users. Modest number of roles. Most or all users belong to just one role and each role has thousands of members.In short, Enterprise IDM has fewer but more complex users. Extranet IDM has many users and highertransaction rates, but users are very regular. © 2009 Hitachi ID Systems, Inc. All rights reserved. 2
  6. 6. User Provisioning Best Practices2.2 Lifecycle Management and Access ControlUser 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. © 2009 Hitachi ID Systems, Inc. All rights reserved. 3
  7. 7. User Provisioning Best PracticesBusiness Processes IT Processes Hire Retire Resign Finish Contract New Application Retire Application Transfer Fire Start Contract Password Expiry Password Reset Users PasswordsOperating Directory Application Database E-mail ERP Legacy Mainframe Groups System System App AttributesSystems and Applications Figure 1: Managing Each Application in its own SiloBusiness Processes IT Processes Hire Retire Resign Finish Contract New Application Retire Application Transfer Fire Start Contract Password Expiry Password Reset Identity Management System Users PasswordsOperating Directory Application Database E-mail ERP Legacy Mainframe Groups System System App AttributesSystems and Applications Figure 2: Managing All Applications Concurrently © 2009 Hitachi ID Systems, Inc. All rights reserved. 4
  8. 8. User Provisioning Best PracticesIn 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. © 2009 Hitachi ID Systems, Inc. All rights reserved. 5
  9. 9. User Provisioning Best Practices3 Business Drivers for Enterprise Identity ManagementThere 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 Containment3.1.1 ChallengesIneffective 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 SolutionsConsolidating 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 once per user per system. This requires less attention from security administrators, as compared to per- system administration. © 2009 Hitachi ID Systems, Inc. All rights reserved. 6
  10. 10. User Provisioning Best Practices • 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 in hours where authorization is required – again rather than days with manual, per-system processes.3.2 Security Threats3.2.1 ChallengesIneffective 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 question is gone. Unused accounts are an ideal target for intruders, as no-one is likely to notice intruder lockouts and other anomalous behaviour. • Dormant accounts: As users change responsibilities, they may no longer require access to some systems, and will stop logging in. Dormant accounts may persist for years, especially since their owner users remain in the organization. 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 prevent both malicious and accidental intrusions, and to ensure that policies regarding internal controls are correctly 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. As a result, business users may attempt to bypass normal change control processes, especially when rushed. Under such circumstances, inappropriate security rights may be granted to users, without any accountability. • 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 eliminates any possibility of accountability for system administrators. • Weak standards enforcement: © 2009 Hitachi ID Systems, Inc. All rights reserved. 7
  11. 11. User Provisioning Best Practices Manually created user profiles may be inconsistent, and cannot be guaranteed to comply with policy or corporate standards. As a result, some users may be setup with excessive privileges, some with too few, etc.3.2.2 SolutionsConsolidating 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 have proper 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 contemporary setup standards.3.3 Regulatory Compliance3.3.1 ChallengesRecent 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 have access privileges. © 2009 Hitachi ID Systems, Inc. All rights reserved. 8
  12. 12. User Provisioning Best PracticesSome 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, so they write them down. – Many systems are unable to enforce effective password quality, history and expiry policies. As a result, users have weak (guessable) passwords. – When users inevitably forget their passwords or inadvertently trigger a lockout, they call the help desk for assistance. Help desk authentication of callers is often weak or non-existent, which makes 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 ability to reset passwords for current users. • Authorization: – AAA infrastructure in applications depends on valid and current user profile data. Failure to update this data in a timely manner, and to deactivate users when required, means that AAA systems enforce the right rules for the wrong people. • Audit: – AAA systems built into systems and applications do not normally track who created a user, who granted an authorization, when and why. This information is required to meet regulatory audit requirements.3.3.2 SolutionsEffective 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 users must 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 to getting service to resolve password or intruder lockout problems. © 2009 Hitachi ID Systems, Inc. All rights reserved. 9
  13. 13. User Provisioning Best Practices – 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 that AAA 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 updated what, when and why. – Periodic certification of current user access rights supports mandatory audit of internal controls, stipulated by a variety of regulations. © 2009 Hitachi ID Systems, Inc. All rights reserved. 10
  14. 14. User Provisioning Best Practices4 Human FactorsIdentity 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 security entitlements 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 make such 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, what it 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 where there may be a significant time lapse between scheduled training and actual use of the system, it is 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. © 2009 Hitachi ID Systems, Inc. All rights reserved. 11
  15. 15. User Provisioning Best Practices5 Enforcing StandardsOne 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 Practices5.1.1 Login ID AssignmentClearly, 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 be compatible with all systems, including legacy. This means a maximum length of 7 or 8 characters, and use of only letters and digits in login IDs. © 2009 Hitachi ID Systems, Inc. All rights reserved. 12
  16. 16. User Provisioning Best Practices • Make login IDs globally unique. Do not assign the same ID to two different users on two different systems, 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, in perpetuity. This protects the sanctity of audit records. • Do support longer login IDs, such as full name, SMTP address or fully qualified directory path, but only as secondary identifiers. Longer IDs may be convenient for users, but do not support effective administration requirements as laid out above. • Even where a hierarchical namespace is used, maintain a flat namespace for CNs. In other words, no CN 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 IDs should 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 a unique ID. • Combine the first four letters of the user’s surname, followed by first and second initial, followed by two 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 AuthorizationRequests 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). © 2009 Hitachi ID Systems, Inc. All rights reserved. 13
  17. 17. User Provisioning Best PracticesIn 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 asset where 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. © 2009 Hitachi ID Systems, Inc. All rights reserved. 14
  18. 18. User Provisioning Best Practices6 Administration ProcessesAs 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 existing user profiles or deactivate users. Requests are automatically routed to business users with suitable authority, 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 multiple managed systems from a single security administration console, that creates a consolidated view of multiple 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 ID Identity Manager (formerly ID-Synch™)) to implement changes initiated on another system (e.g., a partner’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. © 2009 Hitachi ID Systems, Inc. All rights reserved. 15
  19. 19. User Provisioning Best Practices6.1 Automated Change PropagationAutomated 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 system detects this event, notes that it is in scope and reformats the event into workflow requests to create a Windows/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 system detects this and sets the same date in the user’s IDM profile. A batch process runs nightly and automatically submits “deactivate all accounts” workflow requests for every user whose termination date has passed. 3. A rogue administrator adds his accomplice’s login account to the Domain Admins AD group. The user provisioning system detects this new group membership, removes the user from the group and sends an SMS message describing what it detected to a security officer. Systems Target of Record Systems List List people Auto accounts discovery Identity Create, Identity Cache delete, Synchronization update accounts Updates Invitations, Notifications Workflow Transaction Authorizers Manager Manager Approve / reject Connectors Figure 3: Automatic Propagation of Changes in User Profile Data6.1.1 When to useAutomatic change propagation is effective if and only if: • A system of record exists. • That system of record has accurate information about users. © 2009 Hitachi ID Systems, Inc. All rights reserved. 16
  20. 20. User Provisioning Best Practices • 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 ScopeIn 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-mail accounts and Internet access can be setup for all new employees. • Automatically deprovision all systems access to terminated users. Regardless of how users came to have various accounts – when they have left the organization, in most environments, every access should be deactivated.More fine-grained access rights are normally best left to other processes.6.1.3 How to useAutomation 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. © 2009 Hitachi ID Systems, Inc. All rights reserved. 17
  21. 21. User Provisioning Best Practices6.1.4 Pitfalls to avoidHR 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. © 2009 Hitachi ID Systems, Inc. All rights reserved. 18
  22. 22. User Provisioning Best Practices6.2 Self service workflowA 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 Workflow Transaction Form Auto- Manager Manager input reminders Connector Hitachi ID Management Suite Validation / Delegated Approval Approved? completion authority form Authorizer Auto- routing escalation E-mail E-mail invitations notification Target Systems Authorizers Figure 4: Self Service Security Administration Workflow © 2009 Hitachi ID Systems, Inc. All rights reserved. 19
  23. 23. User Provisioning Best Practices6.2.1 When to useSelf 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 ScopeUsers, 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 useIt 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 requesters to 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 allowed to make? © 2009 Hitachi ID Systems, Inc. All rights reserved. 20
  24. 24. User Provisioning Best Practices • How will each type of request be validated (i.e., syntax validation of input fields, code lookups and consistency checks). • Who are appropriate authorizers for each type of request? Typically some combination of managers in 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 should requests be escalated from unresponsive authorizers to alternate, replacement authorizers? • What parts of a request are authorizers allowed to see? For example, social security numbers and the 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, and a 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 request before it is considered to be ready for fulfillment.6.2.4 Pitfalls to avoidIn 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. © 2009 Hitachi ID Systems, Inc. All rights reserved. 21
  25. 25. User Provisioning Best Practices6.3 Consolidated user administrationConsolidated 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. Transaction Security Manager admin UI Create, Target read refresh delete, Systems current current update Administrators Identity accounts state Cache state Connectors Figure 5: Consolidated and Delegated User Administration Console6.3.1 When to useConsolidated 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 ScopeIn 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. © 2009 Hitachi ID Systems, Inc. All rights reserved. 22
  26. 26. User Provisioning Best Practices • 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 How to useConsolidated 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.6.3.4 Pitfalls to avoidConsolidated 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. © 2009 Hitachi ID Systems, Inc. All rights reserved. 23
  27. 27. User Provisioning Best Practices6.4 Delegated user administrationDelegated 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 useDelegated 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 ScopeAll 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 useThe key decisions that a delegated user administration system must make are: © 2009 Hitachi ID Systems, Inc. All rights reserved. 24
  28. 28. User Provisioning Best Practices • Does a given user, who attempts to sign into the delegated user administration system, actually have the 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 are allowed, 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 or department 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 a given 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.6.4.4 Pitfalls to avoidDelegated 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. © 2009 Hitachi ID Systems, Inc. All rights reserved. 25
  29. 29. User Provisioning Best Practices7 Internal ControlsEffective 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, if required.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. © 2009 Hitachi ID Systems, Inc. All rights reserved. 26
  30. 30. User Provisioning Best PracticesAccess 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 them to identify any staff (user profiles) that no longer work for the organization. These will be removed later. • For each remaining, legitimate user, an access profile is displayed, with a list of login accounts and specific 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 are appropriate. • 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, accounts and group memberships being deleted from target systems. • Certifications are collected up through the organization’s hierarchy. Manager A is unable to complete his own certification until all of his subordinate managers (B, C, ...) have likewise completed their own certifications. This creates downward pressure through an organization to complete the review process, and leads to global completion of the certification. © 2009 Hitachi ID Systems, Inc. All rights reserved. 27
  31. 31. User Provisioning Best Practices 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 before asking the next. • Assume that some authorizers will not respond on time, so ask more authorizers than are actually required 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 a single, global authorization process, and fill in the details, such as form validation logic and authorizer routing, for each variation. • Setup a global user administration console for security officers, to eliminate the use of one-per-system tools. • Retain native platform administration tools for specialized tasks. Do not assume that a consolidated infrastructure 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.500, 1401 - 1 Street SE, Calgary AB Canada T2G 2J3 Tel: 1.403.233.0740 Fax: 1.403.233.0725 E-Mail: File: /pub/wp/documents/bestpractices/idsynch/ Date: November 1, 2004