This document introduces best practices for managing users,
identity attributes and entitlements in a typical "corporate"
The focus is on organizations with 1,000 to 10,000 internal users,
such as employees or contractors. They may be
corporations or non-profit organizations such as government,
healthcare or military entities.
Users in these environments are normally provisioned
physical assets, such as a cubicle, desk, chair, phone, PC and
building access badge.
Users in these environments are also provisioned logical
access, such as an Active Directory login account, Exchange
mail folder, Windows home directory and a variety of application
The objective of this document is to identify business processes
that drive changes to users and entitlements in an organization
that fits this description and to offer best practices for each
Organizations that are able to adopt best practices processes will
benefit both from optimized change management and from reduced
total cost associated with automating their processes on an identity
and access management (IAM) platform.
Integrations and manual fulfillment
At a minimum, an identity and access management system should integrate
A data feed from human resources (HR) to trigger automatic
setup, modification and deactivation processes.
It should not be assumed that all the data from HR is
correct. Managers assigned to staff, department codes,
contact information and more may be obsolete or simply wrong.
Changes to HR data and in particular adds and deletes, can
generally be considered to be accurate and can be used to
Exchange or Office 365, for e-mail.
Windows file servers, for home directories.
Here it is assumed that AD/Exchange/Windows are used, simply because
these are common systems for directory, e-mail and
filesystem services. Alternate products, such as Google Apps, are
managed where they are used.
Initially, an IAM system can invite human system administrators to
complete authorized changes on other applications. Over time, other
systems should be integrated, in a sequence determined by the frequency
of changes that they require.
Integration with an incident management system is also important
and should support:
Automatically creating incidents to reflect events such as
user creation and password resets, for consolidated record
keeping and analytics.
Allowing users to request access for new hires and initiate terminations
through the incident management system.
Many organizations use a service catalog or incident management
system as a portal for users to make common requests, such as
to provision new-hires or deactivate departing staff.
This type of web portal includes options for hardware (e.g., what kind
of PC or laptop should the new hire get), connectivity, office
space and more.
This sort of portal can also trigger activity around asset
collection -- retrieving a departing user's laptop, building access
badge and more.
It is natural to extend such onboarding and deactivation forms
to include requests to enable or disable logical access, with
API-level integration forwarding the request details to the
identity management system.
The identity management system should report back to the incident
management system as it either completes or rejects sub-tasks.
All these integrations are illustrated in Figure [link].
Integrations between IAM system and AD, Exchange, Windows, HR and incident management