Standard IAM Business Processes: Corporate / Intranet Deployment

Standard IAM Business Processes

Corporate / Intranet Deployment

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

http://Hitachi-ID.com/

http://Hitachi.com/

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 militaryentities.

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 loginaccount, 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 entitlementsin 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 changemanagement and from reduced total cost associated with automating their processes on an identity andaccess 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 deactivationprocesses.

(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 beaccurate 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 commonsystems for directory, e-mail and filesystem services. Alternate products, such as Lotus Notes, should bemanaged where they are used.

Initially, an IAM system can invite human system administrators to complete authorized changes on otherapplications. Over time, other systems should be integrated, in a sequence determined by the frequency ofchanges 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 reflect 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 usersto 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 thenew hire get), connectivity, office space and more.

(c) This sort of portal can also trigger activity around asset collection – retrieving a departing user’slaptop, building access badge and more.

(d) It is natural to extend such onboarding and deactivation forms to include requests to enable ordisable logical access, with API-level integration forwarding the request details to the identitymanagement system.

(e) The identity management system should report back to the incident management system as iteither 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 todifferent 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 serverson appropriate servers, etc.

While these rules really do vary from one organization to another, following are some suggested bestpractices:



Object / identifier Recommended process

samAccountName(short, unique login IDs)

1. Assign new IDs to all new users – never reuse the ID of aformer user.

2. If possible, assign IDs numerically. Name-based IDs maybe 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 maychange 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 auser’s ID in response to a name change. This shouldbe a carefully controlled and manual process, since itmight break batch jobs, scheduled jobs, e-mail routingrules, etc.

5. Keep the ID short (8 or fewer characters) – this reducestyping effort for the user and enhances compatibility withlegacy applications.

6. IDs should be considered to be case-insensitive – i.e.,ABC123 and abc123 should be considered to be the sameID.

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 likelyto change.




E-Mail address

1. The norm in most organizations is first.last@orgname.

2. Where required, a middle initial should be added foruniqueness: The norm in most organizations isfirst.initial.last@orgname.

3. Where adding middle initial is not sufficient to get a uniqueID, adding a unique number before the @ sign is reasonable:The norm in most organizations isfirst.initial.last.num@orgname.

4. Never reuse old e-mail addresses – always assign newones, even if the old ones are associated with long-goneindividuals. This prevents the situation where an employeeleaves and at some later date an e-mail is received by adifferent person containing sensitive information relating tothe former employee – a potential liability problem for thecorporation.

5. Consider changing the user’s e-mail address in the event ofa future name change. This should be a carefullycontrolled, manual process since other data may depend onthe old address. The old e-mail address should always beretained, as an alias for the new ID.

Directory OU container

1. Most organizations use directory containers (OUs) tostructure 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 numberof users in a single directory container is not in the tens ofthousands.

4. When implementing business logic to place users into anappropriate OU, include logic to move the user’s account toa new OU if key variables, such as the user’s location ordepartment, change.




Directory CN for theuser

1. While multiple users may have the same CN in their fullyqualified name, so long as their accounts are in differentOU’s, assigning only locally-unique CNs is a mistake, as itcan trigger problems when a user’s account is moved to anew OU.

2. The best practice is to make the CN the same as the user’ssamAccountName - a short, globally unique identifier.

Placement of mail folder

1. It is best to select a mail server that is physically near theuser’s usual place of work.

2. If multiple mail servers match, if a central cluster of serversis used or if the local mail server is full, select a mail serverbased on available free disk space.

3. Move the user’s mailbox to a new mail server if the usermoves to a new location in the future.

4. In Exchange 2010, the mail server itself can implement theabove logic.

Placement of homedirectory

1. It is best to select a file server that is physically near theuser’s usual place of work.

2. If multiple file servers match, if a central cluster of servers isused or if the local file server is full, select a file serverbased on available free disk space.

3. Move the user’s home directory to a new mail server if theuser 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 otherroles. 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 ofentitlements, 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 ortwo 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 tousers also rises. This cost can become prohibitive if the number of roles grows into the hundreds orthousands.

3. Most business users do not have the skills, time or inclination to assist in the definition of roles, so thecost of role maintenance realistically lies with the IT organization, who must consult with the businessto 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 securityentitlements 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 changeshave 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 assignedan entitlement.

4. Focus on developing roles for large communities of users with identical security needs. Graduallyexpand 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) ratherthan defining a new role.

The remainder of this document will only make passing reference to roles and RBAC, as the guidanceoffered 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 HRdata 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 userswho appear in the HR data feed – typically this is limited to employees. The password for newly createdaccounts – 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.) isavailable, 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 beasked to set the employee’s initial password manually and communicate that password directly to thenew hire.

3. Where neither PII data nor manager IDs are available, new hires should be required to physically visitan 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 newhires. 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 dependson the requirements of each organization – there is no best practice here. Options include a contractormanagement 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 requestsportal should be restricted so that requests cannot be used for employees. This restriction is toprevent 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 isthe 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 managershould still be invited to approve the change. This process can be used to help managers understandthe 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 submitchange requests on behalf of managers. Engaging security officers to fill out change requests on the identitymanagement 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 businessusers 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, inorder to realize cost savings from the system. Organizations should carefully manage this transition, sincemany managers will prefer to just call IT security and verbally ask for changes, rather than filling in formson a request portal.



7 Change authorization workflow process

In a variety of scenarios, including the manager-initiated onboarding use case described above, one useror process will request a change and one or more additional users will have to review and either approve orreject that change.

Since business users may be too busy to respond promptly and may not respond at all, a number ofstrategies 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’sapproval 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 requestbefore inviting the next. This substantially shortens the approvals process because the total time toapprove a request will be the time required by by the single slowest authorizer to reply, rather than thetotal 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 systemwhere 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 byinvalid requests is small.

(d) The requests which are rejected are almost always due to user input errors, rather than attemptsto 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 needsand these are often urgent. Users generally prefer short SLA to occasional nuisance invitatione-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 sentnumerous 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 theauthority to approve the change request in question. This escalation path also motivates authorizersto 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 originalauthorizer and anyone invited via escalation, so they know that no further action is required.

7. Check authorizers’ out-of-office e-mail status. Authorizers who are known to be unavailable should bereplaced immediately (pre-emptive escalation), rather than waiting for them to fail to respond.



8 Changes to user profiles 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 normallyrequire 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 requestchanges 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 contactinformation, 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 newdepartment’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 groupmemberships, 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 adirectory of corporate user phone numbers, e-mail addresses and office locations.



9 Managing membership in security groups and mail distributionlists

By default, the identity management system should support user and manager requests for changes tomembership in all groups on Active Directory. The default authorization for group membership changesshould be each group’s owner. Where no group owner is defined, a single, global authorizer should beused – 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, achange in the user’s assigned business role should be modeled by adding one or more and removing oneor 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 bean 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 entitlementssince 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 actuallyneeded.

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 theeffective date of the role change (review to be performed by the new manager, to confirm that required newentitlements are granted), or twice – at the end of the transition period (second review to be performed bythe 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 ofextended 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 beterminated, or a contractor may be concluded. Permanent deactivation is almost always performed in threesteps:

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 topermanently 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 datesshould be automatically transferred to user profiles in the IAM system.

A separate, regularly scheduled batch process should examine user profiles and automatically disable thosewhose expiration date has elapsed. The same job should permanently delete accounts that were disabledsufficiently long ago – for example, at least 90 days in the past. This allows time for managers, IT staff orothers 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 betweenwhen HR sets a termination date and when the user is actually disabled. To do this, HR staff must haveboth 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 generallyhave the ability to sign into an HR system. Managers should be able to sign in and set termination dates fortheir direct or indirect reports.

Once a termination date has been set, the process is the same as the HR initiated, scheduled terminationone 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 ifthe 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 subjectto 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) afteraccess 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 accesscertification, 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 owneror 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 determinewhether the user is truly new, or a rehire. To do this, the new user’s information must be compared againstdata about all known users, including active users but also those who have been terminated at some pointin 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 theprocess should terminate and participants notified.

2. If a rehire is allowed, ask for security intervention, since the old profile should be reactivated, ratherthan creating a new user profile for the same person. Reactivating an old profile is preferable tocreating a new one as it creates continuity in the audit record. The motivation here is the same as themotivation 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 withprofile 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 membershipin 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 dangerouscombinations of security rights.

One way to address this is to leverage role-based access control. This way, a role change triggers both theaddition of new and removal of old security entitlements. As mentioned in Section 5 on Page 8, full-scaleand 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 periodicallyinvite 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 calledaccess 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 worlddid 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’smore the manager’s function.

2. Invite application, group or data owners to review lists of users with access to their application, groupor data, so long as the list is not too long (say under 100 users) and so long as they can be reasonablyexpected 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 thelast certification process.

5. Perform certifications regularly – every 6 or 12 months.

6. Automatically submit workflow requests to deprovision access whenever a certifier flags somethingfor 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 thechange.

14 Self-service password management

In most organizations, users sign into systems and applications with an ID and password. When usersmis-enter their password, they can trigger an intruder lockout, which prevents them from signing in for aperiod 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 theirpasswords 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 theirpassword 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 mechanismand 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 outof their Windows login prompt, including when the user is away from the office – i.e., over WiFi and aVPN if necessary.

Where full disk encryption software is used, a mechanism should be provided, typically via a telephone userinterface, 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 forusers 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 toverify that the workload it processes is in line with the volume of changes currently experienced by theorganization. This requirement can best be met by scheduling a set of reports to run automatically anddeliver 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 ongoingclean-up to assign appropriate owners to every object.

An identity management system should send alerts – typically e-mails – to interested parties as a result ofa 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 Administratorson 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: [email protected]

File: /pub/wp/documents/iam-saas/corporate/business-processes-1.texDate: 2011-07-26


Standard IAM Business Processes: Corporate / Intranet Deployment

Technology

access management system

iam system

incident management

identity management

access management iam

deactivation processes

logical access

access badge