Standard IAM Business Processes: Corporate / Intranet Deployment

Standard IAM Business Processes
Corporate / Intranet Deployment
© 2014 Hitachi ID Systems, Inc. All rights reserved.

Contents
1 Introduction 1
2 Integrations and manual fulfillment 1
3 User schema 3
4 Unique identifiers and object location 4
5 Role-based access control 8
6 Onboarding new users 9
6.1 HR driven automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2 Manager initiated requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.3 The role of security officers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7 Change authorization workflow process 11
8 Changes to user profiles and entitlements 12
8.1 Self service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.2 Manager initiated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.3 HR initiated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.4 IT security initiated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.5 No direct relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9 Managing membership in security groups and mail distribution lists 13
10 Role changes 13
11 Temporary and permanent access deactivation 14
11.1 HR initiated, scheduled termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.2 HR initiated, immediate termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.3 Manager requested, scheduled termination . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.4 Interactive, immediate termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.5 Clean-up of terminated user profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
12 Returning users / rehire scenarios 16
i

Standard IAM Business Processes: Corporate / Intranet Deployment
13 Periodic access reviews 16
14 Self-service password management 17
15 Reports and alerts 18
© 2014 Hitachi ID Systems, Inc. All rights reserved.

1 Introduction
This document introduces best practices for managing users, identity attributes and entitlements in a typical
“corporate” environment:
1. 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.
2. Users in these environments are normally provisioned physical assets, such as a cubicle, desk, chair,
phone, PC and building access badge.
3. 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 security entitle-
ments.
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 process.
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.
2 Integrations and manual fulfillment
At a minimum, an identity and access management system should integrate with:
1. A data feed from human resources (HR) to trigger automatic setup, modification and deactivation
processes.
(a) 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.
(b) Changes to HR data and in particular adds and deletes, can generally be considered to be
accurate and can be used to trigger changes.
2. Active Directory.
3. Exchange, for e-mail.
4. Windows file servers, for home directories.
Here it is assumed that AD/Exchange/Windows are used, simply because these are by far the most common
systems for directory, e-mail and filesystem services. Alternate products, such as Lotus Notes, should be
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.
© 2014 Hitachi ID Systems, Inc.. All rights reserved. 1

Integration with an incident management system is also important and should support:
1. Automatically creating incidents to reﬂect events such as user creation and password resets, for con-
solidated record keeping and analytics.
2. Allowing users to request access for new hires and initiate terminations through the incident manage-
ment system.
(a) 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.
(b) This type of web portal includes options for hardware (e.g., what kind of PC or laptop should the
new hire get), connectivity, ofﬁce space and more.
(c) This sort of portal can also trigger activity around asset collection – retrieving a departing user’s
laptop, building access badge and more.
(d) 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.
(e) 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 1.
Figure 1: Integrations between IAM system and AD, Exchange, Windows, HR and incident management

3 User schema
User profiles typically contain the following information:
1. Primary login ID (e.g., as used on AD).
2. Employee number (if different from above).
3. First and last names.
4. Middle initial.
5. Work contact information:
(a) Language preference (for multi-lingual organizations).
(b) E-mail address.
(c) Office phone number.
(d) Mobile number.
(e) Building code.
(f) Floor / section.
(g) Cubicle / office number.
6. Organizational information:
(a) User type (e.g., E=employee, C=contractor, etc.).
(b) Date of hire.
(c) Department code.
(d) Manager’s user identifier.
Privacy-sensitive data may also be included, subject to access controls that limit who can see it:
1. Data that could be used to impersonate the user:
(a) Primary citizenship.
(b) Social security number / social insurance number.
(c) Date of birth.
(d) Mother’s maiden name.
2. Home contact information:
(a) E-mail address.
(b) Home phone number.
(c) Mobile phone number.
(d) Mailing address.
User profiles may contain technical data, which should be hidden from users to avoid confusion and ques-
tions:

1. Home directory UNC path.
2. Mail server.
3. Home directory server.
4. Mail folder disk quota.
User profiles may also contain data which is hidden from the user because it is confidential:
1. Scheduled termination date.
2. Scheduled reactivation date.
3. Actual termination date.
4. Rehire allowed (Y/N)?
5. Termination notes.
6. Previous termination date (this user was rehired).
These profile attributes should be collected into groups, so that different access rights can be granted to
different combinations of requester, recipient and category of data.
4 Unique identifiers and object location
An identity management system must enforce a number of rules regarding the assignment of unique IDs,
the placement of AD accounts in appropriate OUs, the placement of mail folders and home directory servers
on appropriate servers, etc.
While these rules really do vary from one organization to another, following are some suggested best
practices:

Object / identifier Recommended process
samAccountName
(short, unique login IDs)
1. Assign new IDs to all new users – never reuse the ID of a
former user.
2. If possible, assign IDs numerically. Name-based IDs may
be more friendly, but they are costly to support when users’
names change.
3. Never base a user’s ID on their job code, as this may
change but the ID should remain the same.
4. Where name-based IDs are used:
(a) A suffix is often needed, to avoid collisions.
(b) Plan for the process that will be used to change a
user’s ID in response to a name change. This should
be a carefully controlled and manual process, since it
might break batch jobs, scheduled jobs, e-mail routing
rules, etc.
5. Keep the ID short (8 or fewer characters) – this reduces
typing effort for the user and enhances compatibility with
legacy applications.
6. IDs should be considered to be case-insensitive – i.e.,
ABC123 and abc123 should be considered to be the same
ID.
A good policy is “first 4 letters of first name plus 4 digit sequence”
– for example, the third “Michael” user would be MICH0003.
Using first names is better than surnames as they are less likely
to change.

E-Mail address
1. The norm in most organizations is first.last@orgname.
2. Where required, a middle initial should be added for
uniqueness: The norm in most organizations is
first.initial.last@orgname.
3. Where adding middle initial is not sufficient to get a unique
ID, adding a unique number before the @ sign is reasonable:
The norm in most organizations is
first.initial.last.num@orgname.
4. Never reuse old e-mail addresses – always assign new
ones, even if the old ones are associated with long-gone
individuals. This prevents the situation where an employee
leaves and at some later date an e-mail is received by a
different person containing sensitive information relating to
the former employee – a potential liability problem for the
corporation.
5. Consider changing the user’s e-mail address in the event of
a future name change. This should be a carefully
controlled, manual process since other data may depend on
the old address. The old e-mail address should always be
retained, as an alias for the new ID.
Directory OU container
1. Most organizations use directory containers (OUs) to
structure their user list.
2. Some organizations use a geographic hierarchy,
departments or other variables to structure their directory.
3. A flat name space can also be used, so long as the number
of users in a single directory container is not in the tens of
thousands.
4. When implementing business logic to place users into an
appropriate OU, include logic to move the user’s account to
a new OU if key variables, such as the user’s location or
department, change.

Directory CN for the
user
1. While multiple users may have the same CN in their fully
qualified name, so long as their accounts are in different
OU’s, assigning only locally-unique CNs is a mistake, as it
can trigger problems when a user’s account is moved to a
new OU.
2. The best practice is to make the CN the same as the user’s
samAccountName - a short, globally unique identifier.
Placement of mail folder
1. It is best to select a mail server that is physically near the
user’s usual place of work.
2. If multiple mail servers match, if a central cluster of servers
is used or if the local mail server is full, select a mail server
based on available free disk space.
3. Move the user’s mailbox to a new mail server if the user
moves to a new location in the future.
4. In Exchange 2010, the mail server itself can implement the
above logic.
Placement of home
directory
1. It is best to select a file server that is physically near the
user’s usual place of work.
2. If multiple file servers match, if a central cluster of servers is
used or if the local file server is full, select a file server
based on available free disk space.
3. Move the user’s home directory to a new mail server if the
user moves to a new location in the future.

5 Role-based access control
Roles are collections of security entitlements – login accounts, membership in security groups and other
roles. They can be used to more conveniently and efficiently manage what users can access. Role-
based access control (RBAC) is a strategy for managing security entitlements by assigning collections of
entitlements, rather than individual entitlements to users.
Every organization will have its own roles, based on its business and structure. As a result, there can be no
“standard set of roles” that apply to multiple organizations.
When applying roles to user rights, it is helpful to consider some basic guidance:
1. Roles are most helpful if they can be applied to many users. A role that can only be used by one or
two users does not add value, and most likely will lower efficiency.
2. As the number of roles grows, the cost of maintaining role definitions and rules that assign roles to
users also rises. This cost can become prohibitive if the number of roles grows into the hundreds or
thousands.
3. Most business users do not have the skills, time or inclination to assist in the definition of roles, so the
cost of role maintenance realistically lies with the IT organization, who must consult with the business
to perform this function, but cannot offload this function onto the business.
4. Roles can be combined with other mechanisms, such as user requests for individual entitlements.
This means that it is not necessary to define a role for every user, or to include all of the security
entitlements needed by a given user in that user’s role.
With these considerations in mind, it makes sense to:
1. Begin with a small number of roles – say fewer than 20, and add gradually.
2. Use a hierarchy of roles where practical. This reduces the cost of ongoing administration as changes
have to be made in fewer places.
3. Avoid a deep hierarchy of roles, as this can make it difficult to understand why a user was assigned
an entitlement.
4. Focus on developing roles for large communities of users with identical security needs. Gradually
expand the scope of RBAC to include role definitions for smaller user communities.
5. Avoid roles for users with one-of-a-kind job responsibilities.
6. When a few users within a community have unusual requirements as compared to their peers, con-
sider handling this on an exceptional basis (user gets a role plus some additional entitlements) rather
than defining a new role.
The remainder of this document will only make passing reference to roles and RBAC, as the guidance
offered applies regardless of RBAC adoption.

6 Onboarding new users
There are basically two processes for onboarding new users into a corporation:
1. Detect new hires in the HR data feed and automatically provision them.
2. Empower managers to request access for new hires.
6.1 HR driven automation
This approach depends on the availability of accurate and timely data from HR. In organizations where HR
data is either late or not reliable, this approach should not be attempted.
Where such data is available, it should be used to: automatically create basic access rights for new users
who appear in the HR data feed – typically this is limited to employees. The password for newly created
accounts – on Active Directory and elsewhere – should be a random string, to prevent security compromise.
This means that all new users will require a password reset before they can use their new accounts:
1. Where personally identifying information (PII such as mother’s maiden name, date of birth, etc.) is
available, users can be required to authenticate with their PII before they can reset their initial pass-
word.
2. Where PII data are not available but new employees’ managers are identified, the manager can be
asked to set the employee’s initial password manually and communicate that password directly to the
new hire.
3. Where neither PII data nor manager IDs are available, new hires should be required to physically visit
an IT support individual to set the initial passwords.
6.2 Manager initiated requests
Where HR data is not available, not trusted or not timely, managers should enter access requests for new
hires. This is almost always the case for contractors, vendors and temporary workers, for example.
In this scenario:
1. Only designated managers should be able to request the creation of new user profiles.
2. An approvals process is needed to authorize new user access. Who the authorizer should be depends
on the requirements of each organization – there is no best practice here. Options include a contractor
management group or someone in the management chain of the requester.
3. Managers may be subject to restrictions regarding the user profiles that they request. For example,
the location code and/or department code may be automatically set to be the same as the manager,
or the manager of the new hire may be automatically set to the identity of the requesting manager.

4. If employees are automatically provisioned via an HR feed, the available status codes in the requests
portal should be restricted so that requests cannot be used for employees. This restriction is to
prevent an employee from being provisioned twice – once automatically from the HR feed and again,
via request, due to an impatient manager.
In many cases, the user’s manager is the sole authorizer for changes pertaining to the user. When this is
the policy:
1. If the manager entered the change request, it should be auto-approved.
2. If a security officer or administrative assistant enters a request on behalf of the manager, the manager
should still be invited to approve the change. This process can be used to help managers understand
the system and to encourage them to enter requests directly.
6.3 The role of security officers
Initially, the web portal intended for managers might be mostly used by security officers, who may submit
change requests on behalf of managers. Engaging security officers to fill out change requests on the identity
management system’s portal is helpful both initially and over time:
1. Initially, to prove out the system and work through any usability problems before inviting business
users to use the portal.
2. Over time, to handle more complex use cases.
It is important to transition the bulk of change request input away from security officers to managers, in
order to realize cost savings from the system. Organizations should carefully manage this transition, since
many managers will prefer to just call IT security and verbally ask for changes, rather than filling in forms
on a request portal.

7 Change authorization workﬂow process
In a variety of scenarios, including the manager-initiated onboarding use case described above, one user
or process will request a change and one or more additional users will have to review and either approve or
reject that change.
Since business users may be too busy to respond promptly and may not respond at all, a number of
strategies should be considered to elicit prompt and reliable action:
1. Always invite more users than are strictly required to approve a change request. This shortens aver-
age response time and improves the odds of getting a response at all. For example, if one person’s
approval is required, invite two. If two are required, invite at least three, etc.
2. Invite all the relevant authorizers at the same time. Do not wait for one authorizer to approve a request
before inviting the next. This substantially shortens the approvals process because the total time to
approve a request will be the time required by by the single slowest authorizer to reply, rather than the
total of response times of multiple authorizers.
(a) Some organizations argue that sequential approvals are preferable because they shield subse-
quent authorizers from the nuisance of requests that would otherwise have been rejected earlier.
(b) In practice, most requests are approved – users are not likely to enter requests into a system
where there is transparency and audit trails that would just be rejected.
(c) In most organizations, the overwhelming majority of requests – typically over 90% – are ap-
proved. This means that the maximum “nuisance” effect of late authorizers being bothered by
invalid requests is small.
(d) The requests which are rejected are almost always due to user input errors, rather than attempts
to gain inappropriate access rights. This problem should be addressed as a usability problem,
with form validation, on-screen help text, suitable resource names and so on.
(e) All users prefer rapid response times, since requests are made in order to satisfy business needs
and these are often urgent. Users generally prefer short SLA to occasional nuisance invitation
e-mails.
3. Send non-responsive authorizers reminder e-mails. A reasonable policy is to send a reminder invita-
tion to review a change request every 2 hours during the work day.
4. Invite alternate authorizers (escalation) when a primary authorizer fails to respond, despite being sent
numerous reminders. A reasonable policy is to escalate after three reminder e-mails.
5. Escalate to the manager of the original authorizer. This ensures that the new authorizer will have the
authority to approve the change request in question. This escalation path also motivates authorizers
to respond promptly, because they know that failure to respond will trigger an e-mail to their manager.
6. Allow the original authorizer to respond even after escalation. If this happens, thank both the original
authorizer and anyone invited via escalation, so they know that no further action is required.
7. Check authorizers’ out-of-ofﬁce e-mail status. Authorizers who are known to be unavailable should be
replaced immediately (pre-emptive escalation), rather than waiting for them to fail to respond.

8 Changes to user proﬁles and entitlements
8.1 Self service
Users should be able to update their own contact information, and in particular their home contact informa-
tion.
Some change requests, especially those without a security implication, should not require authorization.
For example, a self-service update to a user’s home mailing address or phone number should not normally
require approval.
Users should be able to request access to new applications and security groups.
8.2 Manager initiated
Managers should be able to modify work contact information for their direct and indirect reports and request
changes to their application access and security groups
Managers should be able to see and modify termination dates, but only for users that report to them.
8.3 HR initiated
HR should be able to see and modify PII for all users, to set termination dates and to change user status
(e.g., between employee, contractor, etc.). HR should also be able to modify home and work contact
information, department code and manager ID.
HR alone should be able to request changes in user names.
HR initiated changes that modify the department code or manager ID should be authorized by the new
department’s head or the new manager, respectively.
HR initiated termination may require approval by the manager of record.
8.4 IT security initiated
IT security should be able to directly manipulate user status, termination date, application access and group
memberships, typically without waiting for approvals.
8.5 No direct relationship
Where there is no direct link between two users, a requester should be able to see but not modify a recip-
ient’s name, work contact information and organizational information. This enables the system to act as a
directory of corporate user phone numbers, e-mail addresses and ofﬁce locations.

9 Managing membership in security groups and mail distribution
lists
By default, the identity management system should support user and manager requests for changes to
membership in all groups on Active Directory. The default authorization for group membership changes
should be each group’s owner. Where no group owner is defined, a single, global authorizer should be
used – preferably someone with the ability to set the ownership on groups.
10 Role changes
For users whose entitlements were originally granted as a result of the roles the user was assigned, a
change in the user’s assigned business role should be modeled by adding one or more and removing one
or more roles to the user profile within the identity management system.
For users whose entitlements were not originally granted using roles, a change in business roles may be
an opportunity to apply identity management roles to the user profile.
Changes in a user’s business role often have to be modeled using, at least in part, individual entitlements
since the user’s new business role may not have an associated identity management role definition.
Role changes are often triggered by changes in the user’s location, department and/or manager.
Role changes should normally support:
1. An effective date, so that the request can be submitted and approved before the change is actually
needed.
2. A transition period, during which old entitlements are retained and new ones are added.
3. An end date, on which old entitlements are finally removed.
A role change should trigger recertification of the user’s entitlements. This might happen just once – on the
effective date of the role change (review to be performed by the new manager, to confirm that required new
entitlements are granted), or twice – at the end of the transition period (second review to be performed by
the old manager, to confirm that old entitlements are gone).

11 Temporary and permanent access deactivation
Sometimes the logical access of a user needs to be deactivated temporarily. This happens because of
extended personal time off, such as for maternity leave, sabbatical, short or long term disability, etc.
In other cases, access is deactivated permanently. For example, an employee may retire, resign or be
terminated, or a contractor may be concluded. Permanent deactivation is almost always performed in three
steps:
1. Deactivate access, but leave accounts and other data in place.
2. Some time later, archive data such as home directories and mail folders.
3. Even later, permanently delete accounts and associated data.
A reasonable best practice is to complete data archival in the first week after an account is disabled and to
permanently delete accounts 90 days after they are disabled.
Four mechanisms are normally implemented relating to access deactivation:
11.1 HR initiated, scheduled termination
The HR data feed may specify scheduled termination dates for employees. When this happens, these dates
should be automatically transferred to user profiles in the IAM system.
A separate, regularly scheduled batch process should examine user profiles and automatically disable those
whose expiration date has elapsed. The same job should permanently delete accounts that were disabled
sufficiently long ago – for example, at least 90 days in the past. This allows time for managers, IT staff or
others to archive important data – e-mail folders, home directory contents, etc. after an account is deleted.
11.2 HR initiated, immediate termination
This process must be interactive, since a scheduled job will introduce a delay of up to a full day between
when HR sets a termination date and when the user is actually disabled. To do this, HR staff must have
both access to the identity management web portal to initiate deactivation and be trained to use it.
HR initiated deactivation should be auto-approved, to ensure timely completion.
Other than these two points, the process should be identical to scheduled deactivation.
The batch job that processes these events should typically be scheduled to run at the end of each work day
(e.g., 5PM).

11.3 Manager requested, scheduled termination
This process will be performed on the identity management request portal, since managers do not generally
have the ability to sign into an HR system. Managers should be able to sign in and set termination dates for
their direct or indirect reports.
Once a termination date has been set, the process is the same as the HR initiated, scheduled termination
one above. Normally, the termination date is set from an HR feed but if a manager sets this value:
1. The manager-set value should take precedence.
2. An e-mail should be automatically sent to HR to notify them of the upcoming termination, at least if
the user is an employee.
11.4 Interactive, immediate termination
Security officers should also be able to sign into the web portal to trigger immediate deactivation, not subject
to an approval process. This is identical to the HR initiated immediate termination process.
11.5 Clean-up of terminated user profiles
After a user has been terminated, a variety of clean-up steps are required:
1. Delete the user’s objects on filesystems and mail servers some number of days (typically 90) after
access was disabled.
2. Reassign resource ownership:
(a) On Active Directory, groups normally have owners.
(b) Within the identity management system, users may own groups, roles, template accounts, etc.
3. Re-route change requests:
(a) If the terminated user was an authorizer on any open requests, or was invited to perform access
certification, or was asked to manually implement a change, reassign those tasks to new users.
4. Find a new manager for all direct subordinates:
(a) Update the “manager” attribute of all direct reports of the terminated user, on both Active Direc-
tory and within the identity management system.
In general, the terminated user’s manager will be assigned as a replacement manager, entitlement owner
or workflow participant in each case. The manager should be sent an e-mail notifying him of this change,
to give him an opportunity to request more appropriate updates.

12 Returning users / rehire scenarios
When onboarding new users, be it from an HR data feed or manager requests, it is important to determine
whether the user is truly new, or a rehire. To do this, the new user’s information must be compared against
data about all known users, including active users but also those who have been terminated at some point
in the past:
1. Match on first name, last name and date of birth.
2. Match on private e-mail address.
3. Match on social security number or equivalent.
Wherever a match is found:
1. Check the old profile’s rehire flag. A rehire of this individual may not be allowed, in which case the
process should terminate and participants notified.
2. If a rehire is allowed, ask for security intervention, since the old profile should be reactivated, rather
than creating a new user profile for the same person. Reactivating an old profile is preferable to
creating a new one as it creates continuity in the audit record. The motivation here is the same as the
motivation for not reassigning the IDs of terminated staff to new hires.
3. Allow security officers to override the match, indicating that a truly new person is being hired, but with
profile data matching a former employee or contractor.
13 Periodic access reviews
Users who remain with an organization for a long time tend to change jobs periodically. Whenever this hap-
pens, users request and are granted new access rights – login accounts on applications and membership
in security groups. Users never request access deactivation, so they tend to accumulate security entitle-
ments over time. This can become a serious internal control problem as users acquire toxic or dangerous
combinations of security rights.
One way to address this is to leverage role-based access control. This way, a role change triggers both the
addition of new and removal of old security entitlements. As mentioned in Section 5 on Page 8, full-scale
and fine-grained RBAC can be cost prohibitive, so additional mechanisms are often required.
Another approach used by many organizations and recommended by Hitachi ID Systems is to periodically
invite managers and group owners to review security entitlements assigned to users and differentiate be-
tween (a) those that remain appropriate and (b) those that should be removed. This process is called
access certification.
When implementing access certification:
1. Invite managers to review:

(a) The employment status of their subordinates, to catch cases where a termination in the real world
did not, for whatever reason, trigger deactivation of the user’s profile.
(b) The roles assigned to their subordinates.
(c) The assignment of widely used security entitlements to subordinates. For example, it makes no
sense for someone in IT to certify that a user should have a login ID on Active Directory – that’s
more the manager’s function.
2. Invite application, group or data owners to review lists of users with access to their application, group
or data, so long as the list is not too long (say under 100 users) and so long as they can be reasonably
expected to personally know the users.
3. Whenever a user changes department, location or manager, this transition should trigger recertifica-
tion of all of the user’s entitlements by the user’s new manager of record.
4. Extract entitlement data directly from target systems – do not infer that it has not changed since the
last certification process.
5. Perform certifications regularly – every 6 or 12 months.
6. Automatically submit workflow requests to deprovision access whenever a certifier flags something
for deletion.
7. Wherever a manager flags an item for removal, invite the application owner to approve the change.
8. Wherever an application owner flags an item for removal, invite the user’s manager to approve the
change.
14 Self-service password management
In most organizations, users sign into systems and applications with an ID and password. When users
mis-enter their password, they can trigger an intruder lockout, which prevents them from signing in for a
period of time. Users may forget their password, which also blocks their ability to sign on.
A self-service password reset system should be deployed to help users more effectively manage their
passwords and resolve login problems without having to contact the IT help desk. It should:
1. Invite users to fill in data that can be used to authenticate them in the event that they forget their
password or trigger a lockout. This typically includes:
(a) Answers to standard security questions.
(b) Their own, personally created security question/answer pairs.
(c) If possible, their mobile phone number.
2. Send automatic reminders to users to enroll this profile data.
3. Provide a web page where users can sign in with either their password or another trusted mechanism
and subsequently change their password.
4. Enforce a password policy forbidding the use of easily guessed passwords:
(a) Minimum length – e.g., 7 characters.

(b) Must include mixed case and digits.
(c) Not based on the user ID, name or a dictionary word.
(d) Not the same as any previously used password.
5. Remind users to change their passwords periodically – for example, via an e-mail sent every 90 days.
6. Support authentication of users who have a password problem using a combination of standard se-
curity questions, user-defined security questions and a random PIN sent to the user’s mobile phone.
7. Provide a mechanism for users to access the password reset web page even if they are locked out
of their Windows login prompt, including when the user is away from the office – i.e., over WiFi and a
VPN if necessary.
Where full disk encryption software is used, a mechanism should be provided, typically via a telephone user
interface, for users to re-activate their PC after forgetting the disk encryption password.
Where one time password (OTP) tokens or smart cards are used, a mechanism should be provided for
users to reset a forgotten PIN, get an emergency access password or resynchronize their token clock.
Where users have passwords on multiple systems or applications, their passwords should be synchronized,
so that users have an easier time remembering them and are less incented to write them down. Fewer,
stronger passwords are preferable to distinct but less secure passwords.
15 Reports and alerts
Once an identity management system is in production, it should be monitored to ensure health and to
verify that the workload it processes is in line with the volume of changes currently experienced by the
organization. This requirement can best be met by scheduling a set of reports to run automatically and
deliver their output to the system’s owner. Reports to schedule include:
1. Number of users, accounts, groups and group memberships, total.
2. Number of HR initiated adds and deletes detected, monthly.
3. Number of manager initiated adds and deletes, monthly.
4. Total number of requests submitted, approved and rejected, monthly.
5. Total number of password resets, monthly.
6. Groups or other resources that have no known owner. This should be used to drive an ongoing
clean-up to assign appropriate owners to every object.
An identity management system should send alerts – typically e-mails – to interested parties as a result of
a variety of actionable or questionable events:
1. All terminations, since someone might have to archive files, mail folders, etc.
2. Unauthorized changes detected to membership in sensitive security groups, such as Administrators
on AD.

3. Too many changes detected at any one time in the HR feed (e.g., 1,000 new hires or 1,000 termina-
tions on the same day).
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: sales@Hitachi-ID.com
File: /pub/wp/documents/iam-saas/corporate/business-processes-1.tex
Date: 2011-07-26

Standard IAM Business Processes: Corporate / Intranet Deployment

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (6)

Similar to Standard IAM Business Processes: Corporate / Intranet Deployment

Similar to Standard IAM Business Processes: Corporate / Intranet Deployment (20)

More from Hitachi ID Systems, Inc.

More from Hitachi ID Systems, Inc. (20)

Recently uploaded

Recently uploaded (20)

Standard IAM Business Processes: Corporate / Intranet Deployment