Microsoft Forefront Identity Manager 2010

OXFORD COMPUTER GROUP WHITEPAPER SERIES

Forefront Identity Manager 2010 A Whitepaper from Oxford Computer Group

Oxford Computer Group www.oxfordcomputergroup.com

This Whitepaper from Oxford Computer Group examines some of the features which can be expected from a modern Identity Management platform, and makes use of an example scenario to examine Microsoft’s new software: Forefront Identity Manager (FIM) 2010. In conclusion, we establish that FIM 2010 fulfills these broad requirements, and has the support of complimentary 3rd parties to further enhance the solution.

Microsoft Forefront Identity Manager 2010 – A Whitepaper from OCG

© Oxford Computer Group Worldwide Ltd. 2010

Table of Contents Introduction ...................................................................................................................................................................................... 1

Identity Management and FIM 2010 ........................................................................................................................................... 1

Identity Management – Some Background .......................................................................................................................... 1

Identity ≠ User ...................................................................................................................................................................... 1

Management ≠ Data Synchronization .............................................................................................................................. 2

Not all Responsibility is Defined ....................................................................................................................................... 2

Identity Management Interfaces with Business Processes .......................................................................................... 3

Context = Everything .......................................................................................................................................................... 3

Summary.................................................................................................................................................................................. 4

An Illustrative Scenario .................................................................................................................................................................. 5

Phase 1: Classic Synchronization............................................................................................................................................ 5

Phase 1 Summary .................................................................................................................................................................. 6

Phase 2: Introducing the FIM Portal ...................................................................................................................................... 6

The FIM Service ..................................................................................................................................................................... 7

FIM Delivers Pre-Configured Functionality Out-of-the-Box ..................................................................................... 7

FIM has a flexible schema .................................................................................................................................................... 7

FIM provides configurable UI components .................................................................................................................... 7

FIM controls access to its data via policies .................................................................................................................... 8

Phase 2: Summary ................................................................................................................................................................. 8

Phase 3: Integrating with the Sync Engine ............................................................................................................................ 9

The FIM Management Agent .............................................................................................................................................. 9

Phase 3 Summary ................................................................................................................................................................ 10

Phase 4: Process Integration ................................................................................................................................................. 10

Connecting Active Directory .......................................................................................................................................... 10

Synchronization Rules ........................................................................................................................................................ 11

The FIM Service in Detail.................................................................................................................................................. 11

New components for this Phase ..................................................................................................................................... 12

Phase 4 Summary ................................................................................................................................................................ 13

Phase 5: Password Management........................................................................................................................................... 13

Forgotten Password Reset ............................................................................................................................................... 13

Password Reset System Components ........................................................................................................................... 14

Password Synchronization Components ...................................................................................................................... 14

Phase 5 Summary ................................................................................................................................................................ 14

Phase 6: Certificate Management ......................................................................................................................................... 15

CS Components .................................................................................................................................................................. 15

Phase 6 Summary ................................................................................................................................................................ 16


© Oxford Computer Group Worldwide Ltd. 2010

Can it really be this easy? ....................................................................................................................................................... 16

Careful Change Management is required ..................................................................................................................... 16

Extensions will often be required ................................................................................................................................... 16

Areas where custom solutions are typically required ............................................................................................... 17

System Management: Room for Improvement............................................................................................................ 17

Compatibility with/Upgrade from ILM 2007 ..................................................................................................................... 18

Conclusion ................................................................................................................................................................................. 18

For Further Information ......................................................................................................................................................... 19

Appendices...................................................................................................................................................................................... 20

Appendix 1: Detailed function of the Request Processor ............................................................................................. 20

Appendix 2: Pre-Configured Functionality ........................................................................................................................ 21


© Oxford Computer Group Worldwide Ltd. 2010 Page 1

Introduction This white paper discusses Forefront Identity Manager 2010 (FIM 2010), the newest star in Microsoft’s identity management firmament. It examines the functionality which is to be expected from a modern Identity Management platform, and asks whether the product fulfils these promises.

For Microsoft, FIM 2010 represents a major step forward. ILM 2007, and its predecessor MIIS 2003, have for several years offered very powerful data synchronization solutions which, with significant customization, have been extended into very powerful identity management solutions. FIM provides us with many more out-of-the-box identity management functions, and therefore enables the straightforward configuration of the platform without the need for such extensive customization. Some functions, such as the ability for an end-user to reset their forgotten password, are available for the first time.

While code-based customization is available in FIM as it was in ILM, the majority of an implementation is expressed in the form of policy objects which are made visible in the new FIM Portal. This makes them more transparent and accessible, which is a major improvement over the rather opaque configuration definitions in ILM 2007.

The purpose of this paper is to describe the features of FIM 2010, and set them in context using an example scenario. For more background information about features offered in ILM 2007, as well as the identity management concepts common to both FIM and ILM, you might like to see the whitepapers “Microsoft Identity Lifecycle Manager 2007” and “Provisioning with Microsoft Identity Lifecycle Manager 2007” available under http://www.oxfordcomputergroup.com/resources.aspx.

Identity Management and FIM 2010

Requirements of Identity Management Platforms Before we examine FIM 2010 in detail, we discuss some key requirements which must be fulfilled by an identity management platform.

Identity ≠ User The sales presentations used throughout the industry focus almost exclusively on the management of user accounts. However, the “Identity” in Identity Management does not relate exclusively to Users. While there is a logic to this, in as much as the majority of implementations involve employees, Identity Management can deal with many types of Entity (such that the word identity is sometimes written as (id)entity to make this point) including Groups, Roles, Organizational Units, Cost Centres, Customers, Suppliers, Buildings, SharePoint Sites and many others (though it is rare that all of these are present in a single system). So, broadly, we are in the business of managing the data concerning many different objects of interest to the enterprise as a whole. By extension, therefore, our identity management system has to have technical interfaces with a wide variety of systems, not limited to HR systems and NOSs, but including almost any system which is used to store business data.

Requirement #1: Identity Management systems must be able to handle a variety of types of Identity, and interface with the appropriate systems for this purpose.

http://www.oxfordcomputergroup.com/resources.aspx�



Management ≠ Data Synchronization Many of us have encountered human managers (although not, of course, at our current employers) whose role seems to be the transmission of work generated by others, without the addition of meaningful value. However, we also encounter managers (particularly, of course, at our current employers) who add significant value to the work done in their departments – and so it should be. The parallel with the Identity Management world is apt – the transfer of information from one place to the other (for example, a simple copy from one list of users to another list of users) is often quicker and simpler to perform with tools other than identity management systems. But as soon as things become more complex, so that decisions must be made in different contexts, normalization or validation of data is required, or data transformation according to various rules is needed: then, the management systems show their worth, and provide a useful central point of policy implementation.

It is not, by the way, the aim of this paper to claim that data synchronization is in any way an unworthy goal of an identity management system – on the contrary, a level of synchronization of data is often an absolute prerequisite for any successful identity management, and the gains from centralizing a plethora of point-to-point solutions can be huge – but merely that the ambitions of an identity management system go beyond this. It will, therefore, be necessary in this paper to consider, and indeed to assume, scenarios which go well beyond common simple data synchronization. Hence, this paper will not repeatedly say “in all but the simplest implementations... (the following statement applies)” – it will be taken for granted that we are not referring to the simplest implementations.

Requirement #2: Identity Management systems must offer more than simple data synchronization – they must offer a central point of policy implementation.

Not all Responsibility is Defined Given that business systems are typically responsible for some type of data, does it follow that for every type of data there is a business system? Generally not. There are typically grey areas where some data which is relevant to identity management is not specifically managed by any existing department or system. A classic example of this is the management of external contractors: in many organizations the first that any system hears of a contractor is the request for network access (so that the contractor can work on a given system). The contractors are indeed managed in the sense that:

• each department has a list of “their” contractors, because they have to request their services internally, and

• the purchasing department has a list of contractors because they have to produce the commercial arrangements for the ordering of the services.

There is responsibility to manage requests for contractors, responsibility to manage contracts for contractors – what is missing is responsibility to manage the contractors as identities in themselves.

If this gap is to be filled, there are two components – the establishment of responsibility (which is generally out of the scope of the identity management project) and the establishment of a system in which the contractors are to be managed. In the absence of another system, the identity management system can offer such a platform, including a user-interface, and usually without taking on the organizational responsibility for the management of contractors.

This example concerning Contractors is only one of many. Identity management depends on a variety of data for validation and normalization purposes (such as the standard name for a department, or the street address of a location) which do not necessarily have a readily identifiable or accessible source.



Requirement #3: Identity Management systems should to be able to act as primary sources for certain Identity types, providing an appropriate user interface.

Identity Management Interfaces with Business Processes In the world of business, nothing is fought over more assiduously inside companies than responsibility. Progress is measured in the size of budgets, headcount, areas of authority – and this has practical reasons. It is very important to have clarity over the issue of responsibility – without it, key areas of the business would not function effectively. Who is responsible for keeping data on employees up to date? The HR Department. Who is responsible for managing data concerning the buildings and offices? The Facility Management department. Those responsible for an operational area in the business are acutely aware of this responsibility, and usually have the means to fulfil this responsibility, in the sense that they manage data about it, in some more-or-less appropriate system, and the management of this data is performed according to more-or-less formal processes.

An Identity Management system cannot, and should not, attempt to replace the responsibilities and processes which support the management of core data. It can, however, improve the processes by:

• Raising efficiency: such as automation of data administration via synchronization • Enhancement – such as the addition of workflow-based approvals • Visibility – such as making the results of this process visible – and thus useful – to others.

It can also deliver interconnections between existing processes: for example, the process which manages the arrival of a new employee is often connected to the process which creates their email account via a paper-based process which causes delays and can introduce data errors and inconsistencies due to multiple data entry. In contrast a simple automated solution might be as follows:

• The IDM system detects data in the HR system which indicates that the user has completed the HR-Onboarding process

• The IDM system creates a ticket in the helpdesk system for the creation of an email account

This solution may be slightly unambitious – in reality we might want to implement automation of the email account creation as well – but also realistic. Neither the HR nor the Helpdesk processes have been modified (except perhaps to remove a paper-based form-filling exercise), but the identity management system has added value by making the connection between them smoother.

Requirement #4: Identity Management systems must be able to deliver process integration.

Context = Everything The issue of context follows on from the previous point about process. Managers make decisions about whether to sign the form in front of them based on context – based, in fact, on the data on the form in front of them, coupled with their understanding of the purpose of the process in which they are involved. So a request for an account in the ERP system for an individual employed on a short term contract who was previously a contractor who worked extensively for a direct competitor may be viewed differently from a request for an employee who has been in the organization for 10 years. It is the ability to evaluate context which makes the business process reliable.

Of course, the situation is similar in identity management: if we are to automate business rules, we need to be able to represent context (“This individual is transferring from the Chinese subsidiary into London”) as well as policies based on context (“Individuals transferring from overseas subsidiaries require higher-level approval than those transferring internally”).



Requirement #5: Identity Management systems must be able to represent business context.

Summary We have established the following Requirements:

1. Identity Management systems must be able to handle a variety of types of Identity, and interface with the appropriate systems for this purpose

2. Identity Management systems must offer more than simple data synchronization – they must offer a central point of policy implementation

3. Identity Management systems should to be able to act as primary sources for certain Identity types, providing an appropriate user interface

4. Identity Management systems must be able to deliver process integration 5. Identity Management systems must be able to represent business context



An Illustrative Scenario We will now consider a FIM 2010 implementation scenario in which an identity management system is constructed step by step. This provides the opportunity to examine each of the components of the FIM 2010 platform in turn.

Phase 1: Classic Synchronization In this stage of the project, we have a number of systems connected via the synchronization engine. Data about employees is imported from an HR system; telephone data is imported from a telephone system, and the joined data is exported to an ADLDS instance.

This system can be represented as follows:

The synchronization engine, making use of its SQL Server-based storage (the “SyncDB”) transfers data between the three connected systems. Its Management Agents (“MAs”) are configured appropriately (and we won’t go into detail here) so that the records in the telephone system become correctly joined with the records imported from the HR system to create the aggregation of data that is then exported to ADLDS.

This type of configuration is known as “Classic” configuration because the synchronization rules are defined in components of the synchronization engine itself:

• Management Agents contain rules for the creation, joining and removal of objects, as well as the flow of attributes between the system and the SyncDB

Ser

ver

Com

pone

nts FIM Sync

MAs

SyncDB

ADLDSHR Telephone System

Iden

tity

Sto

res

Nat

ive

Clie

nts

Sync Manager



• At least one code extension is present, to perform the provisioning into ADLDS; it is likely that each Management Agent has its own code extension to implement data transformation and validation policies

This configuration is entirely familiar to those people who have worked with Microsoft Identity Lifecycle Manager 2007 (ILM 2007): the FIM Sync engine is an enhanced version of ILM 2007, and can make use of exactly the same rule configurations. The Synchronization Service Manager (“Sync Manager” in the illustration above) is equally familiar to ILM 2007 users: it has been minimally updated to be compatible with the new features in FIM 2010.

Phase 1 Summary In phase 1, we have a data synchronization system built around the FIM Synchronization Service. The rules for data handling are implemented as Management Agent configurations and in code modules.

This phase demonstrates how FIM fulfils our Requirement 1:

Requirement #1: Identity Management systems must be able to handle a variety of types of Identity, and interface with the appropriate systems for this purpose.

Phase 2: Introducing the FIM Portal Our scenario defines that at the start of the project, our organization has no formal means of managing external employees. In this phase, therefore, we configure the FIM portal to allow employees in our HR Department to manage external employees. To start with, we are not interested in sharing this data, merely editing the data and storing it in the FIM database.

The system components involved with this phase can be illustrated as follows:

The FIM Portal application runs within a Windows SharePoint Services environment, communicating primarily with the FIM Service. The FIM Service provides the major functionality at the heart of FIM, and it is important to understand its purpose.

Ser

ver

Com

pone

nts

AppDB

FIM PortalNat

ive

Clie

nts

FIM Service



The FIM Service The FIM Service runs as an operating system service, managing its SQL Server-based storage, and responding to data requests (issued as Web Service requests) from the portal (or other) application. The requests might be, for example, for read access to data (“Please return the First and Last name attributes of object X”), for modifications (“Please modify the department code for user Y to be ‘IT’”), or for query enumeration (“How many objects does the following query return?”). The FIM Service evaluates the policies which control permissions, to establish whether the request is basically acceptable (and, as we will shortly discuss, it triggers any workflows which are defined as relevant to the request which has been submitted).

We will consider concrete examples of these requests, and how they are handled, once we have described the policies which control their handling.

FIM Delivers Pre-Configured Functionality Out-of-the-Box FIM is delivered with many pre-configured functions, which deal with the management of Users and Groups, for example. Please refer to Appendix 2: Pre-Configured Functionality for a detailed list. As you might expect, FIM is pre-configured very much with Active Directory in mind, so that the default schema for Users and Groups is also defined with AD in mind.

FIM has a flexible schema In the discussion early in this paper, we stated that it is important to be able to manage any number of different types of object. In fact, the FIM AppDB has a schema which is limitlessly extensible, so that any number of attributes and object types (which are referred to as “Resource Types” in FIM) can be defined. The schema in the SyncDB is similarly extensible, so that attributes gathered or generated in the AppDB can be appropriately synchronized to and from target systems. The object types “person” and “group” are pre-configured, as suggested above.

Relationships between objects (“user x has manager y and sits in office z”) are easily defined and easily queried, so that, for example, “give me all users whose managers are assigned offices in London” could be expressed as “/Person/Manager/Office[Location = ‘London’]”.

In our scenario, we want to make use of the built-in Person object type to store details of our external users, but we want to extend the schema to allow us to store information about their external contact information in addition to their internal contact information. We therefore extend the schema so that additional attributes can be stored for each of the external employees, adding attributes ExternalPhone, ExternalFax, ExternalMail and InternalSponsor. This last attribute is intended to allow us to connect all external employees with an internal employee who will take responsibility for them. At present, however, we have no internal employees in the portal, so this will only become useful later!

FIM provides configurable UI components Having created some additional attributes, we have to make them visible to end-users.

The display of the objects stored in FIM is, of course, configurable. A separate display configuration (technically known as a “Resource Configuration Display Configuration” (RCDC)) is available for each of three purposes: Create, View and Edit, so that attributes which are, for example, only relevant during object creation can be made read-only or invisible when the object is later edited. In our case, we simply modify the RCDCs for the Person object type so that the additional attributes are visible.



FIM controls access to its data via policies FIM stores its data in SQL Server tables, and while it is technically possible to access this data directly, such access is not supported by Microsoft. Instead, the data is exposed by the FIM Service via Web Services, as described above, and all data access by clients should be executed via web service requests.

Once the FIM Service receives a request, it has to establish whether to fulfil this request or not. The primary means of access control is via “Permission-Granting” Policies, and we will examine these in some detail now.

Permission-granting policies define a set of requests, using a definition like this:

This policy applies to any request which is made by a Requestor to read or change data in certain attributes on a target object, where the target is in this state before any change and

will be in this state after any change.

The emboldened words and phrases are the configurable elements in the policy, where it is defined exactly which Requestors, which target objects and attributes, and which states will apply to this policy.

Note that the state before and state after components allow us to represent business context. Our example above was “users transferring from an overseas subsidiary are subject to a higher level of approval”. We can implement this policy by defining the state before to be “employee belongs to an overseas subsidiary” and the state after as “employee belongs to the head office”.

Using such policies, then, we can define the conditions in which data access is to be allowed. The policy defines a set of requests to which it applies, and any request which belongs to this set will be granted permission. If a policy is connected with any workflows, these workflows will be triggered when a request arrives which is a member of this set.

For example:

“All users in the HR Department can modify Department Codes”

is a policy statement. This policy statement covers any request which is submitted where:

• The submitting user is a member of the HR department

and

• The requested modification involves a change to the Department attribute.

This example highlights the fact that we need to make certain that our new attributes are included in the appropriate policies, so that our HR staff can manage them.

Phase 2: Summary Now that we have installed the portal and configured its schema, some display configuration and some policies, our HR Staff have a platform to manage external employee objects using the FIM Portal. The rules controlling access to the information concerning the external employees is controlled via policies which are also visible in the portal.

Thus we fulfil the requirements of Requirement 3:

Requirement #3: Identity Management systems should to be able to act as primary sources for certain Identity types, providing an appropriate user interface.



Phase 3: Integrating with the Sync Engine Now that we have begun to gather information about the external employees in the organization, we want to make use of this information. Initially, we want to publish their information in our existing ADLDS instance, so we have to connect the SyncDB with the AppDB.

The FIM Management Agent The integration between the synchronization engine and the SyncDB is achieved using a Management Agent. This agent is specific to FIM, and essentially makes certain that the information in the SyncDB is congruent with the data in the AppDB. This agent does not allow data transformations, so it binds the data in the two databases very tightly – the data which is in the AppDB will be reflected 1:1 in the SyncDB. Note that because there is data in the portal which is only relevant to the portal (display configuration objects, for example) not all data is synchronized with the SyncDB, but rather a configurable subset of the objects in the AppDB is available for synchronization.

We implement a FIM MA, and our system looks like this:

As a result of this integration, the data in the AppDB is synchronized with the SyncDB, in both directions. This means that all the external employees are imported into the SyncDB, and also that all the internal employees are exported into the AppDB. No code or additional configuration is required to achieve this – the FIM MA simply makes sure that the data in the SyncDB is the same as that in the AppDB.

Now that the AppDB contains the internal employees (from the HR system) our HR staff can begin to make the connections between internal and external employees using the InternalSponsor reference attribute.

Ser

ver

Com

pone

nts FIM Sync

MAs

SyncDB


Iden

tity

Sto

res

AppDB

FIM PortalNat

ive

Clie

nts

FIM Service

Sync Manager



Phase 3 Summary We have integrated the external employees’ data into the identity management system, and it is being published alongside the internal employees’ data in our ADLDS, mixed (where appropriate) with telephone data.

The AppDB now contains all internal and external employees, and the external employees are assigned an InternalSponsor.

Phase 4: Process Integration So far, we have a somewhat enhanced data synchronization scenario. While the data is suitably synchronized, the rules governing that synchronization are somewhat hidden. They are embedded in Management Agent configurations, which are only visible through the FIM Synchronization Service Manager interface (and hence essentially only available to administrators), and in code, which is similarly inaccessible to non-technical staff who may have questions about the implementation.

In addition, we are entirely data-driven. However, business processes are rarely entirely deterministic – there are many exceptions to each rule, and as we discussed above, this is why managers are called upon to make decisions based not just upon the data, but also based on their judgement.

The next stage of our implementation involves creating Active Directory accounts with Exchange mailboxes for our external employees. However, this will be controlled by their InternalSponsor, who will be asked to approve the creation of this account. As the account is being created, the initial password created for the new account will be emailed to the Contact so that it can be passed to the external employee.

We wish to achieve this new functionality using transparent policy-driven rules, rather than embedding the rules in the sync engine, so we will be using the new “Declarative Rules” available with FIM. The rules will implement the policies

“External Employees will be added to the system subject to approval from their InternalSponsor.”

“New External Employees will automatically receive an Active Directory account and Exchange Mailbox”

We have a number of new components to build, so let us examine each in turn.

Connecting Active Directory The connection to Active Directory is made by implementing a Management Agent in the Sync Manager. The basic data source information is specified here (domains to be synchronized, user account(s) to be used for the connection, containers to be synchronized, objects and attributes to be synchronized). Once this base data has been specified, the agent is created – however, without any configuration concerning the treatment of the objects and attributes which are found in Active Directory. These configurations will be made in the Portal.

If this management agent is executed, the Synchronization Service will read data from Active Directory, but it will make no changes based on this data, whether in other connected systems or in Active Directory itself, simply because the rules are not yet defined.



Now the system looks like this:

Synchronization Rules Our Policy Statement simply says “external employees will get an AD/Exchange account” – it contains no specifics about the technical implementation – where the mailbox will be stored, what user name should be used, how passwords should be generated, which attributes in Active Directory should be imported from or exported to, and so on. These rules must, of course, be defined: this is accomplished using Synchronization Rules. It is beyond the scope of this paper to describe Sync Rules in detail: we will simply state that they are necessary definitions of our specific technical implementation.

Synchronization Rules which make changes in connected systems (Outbound Sync Rules), as opposed to those which just import information from connected systems (Inbound Sync Rules), are assigned specifically to individual objects. This explicit connection between (in our case) the external employee and the Sync Rule for Exchange is made by a Workflow, and this workflow is in turn triggered by a policy.

It is beginning to get complicated! To understand how the various Portal objects work together to define the business rules governing the Exchange functionality, we need to delve a little deeper into the FIM Service.

The FIM Service in Detail The FIM Service performs a number of tasks which are important for

• the control of access to the read and change data in the portal • the proper handling of requests to change data • the proper response to data which has been changed

Ser

ver

Com

pone

nts FIM Sync

MAs

SyncDB


Iden

tity

Sto

res

AppDB

FIM PortalNat

ive

Clie

nts

FIM Service

Sync Manager

AD/Exchange



The functions provided by the FIM Service are best illustrated as follows:

The Request Processor receives requests via Web Services, and evaluates the other components as appropriate. (A more detailed look at how this occurs can be found in Appendix 1.)

For now, we simply need to identify the types of behaviour which can be configured.

• Permissions: define whether the request is to be accepted. If permissions are not available, the user sees “Access Denied”.

If the request is only to Read data, rather than to modify it, the data is simply returned (provided the permissions for this are available). No further action is undertaken by the Request Processor. The steps below therefore apply to Modify requests. In our example, the request contains the data to “Add a new External Employee”.

• Authentication (AuthN) Workflows require the user to provide some information which confirms their identity. This is used in cases where, for example, no other authentication is possible (e.g. “Forgotten Password” scenarios) or where the activity is sensitive enough to require additional checks.

• Authorization (AuthZ) Workflows are used to implement a variety of checks to ensure that the request is allowable: the easiest to understand is an approval step where another user is invited to answer “Accept” or “Decline” to a prompt (either in the portal or in Outlook).

• Action Workflows are used where further modifications to data are required, based on the change which has just taken place.

New components for this Phase To achieve our goals for this phase, we have created the following components:

• A Management Agent for AD/Exchange • A synchronization rule containing technical details of how to manage AD/Exchange in this case • An Authorization workflow which sends an email to the InternalSponsor, asking for approval to add the

new external employee. • An Action workflow to apply the sync rule, to generate a password for the new account and to send

this password to the InternalSponsor. • A policy, which recognises the “Add New External Employee” requests, grants appropriate

permissions, and triggers the workflows

Having added these components, our system looks something like this:

FIM Service

AuthZWorkflow

AuthNWorkflow

Permissions

AppDB

Request Processor

Action Workflow



Phase 4 Summary The activities in this phase show how we can define policies to recognise business context, and to provide process integration. When the system recognises that a new External Employee is to be created, it triggers appropriate workflows, requests some human decision-making and then implements the required technical steps.

We fulfil therefore

Requirement #4: Identity Management systems must be able to deliver process integration.

and

Requirement #5: Identity Management systems must be able to represent business context.

Phase 5: Password Management To enhance the security of our system, we want to ease the burden on our helpdesk by allowing our employees to reset their own password if they forget their existing one.

We want to make sure that the password used in Active Directory is also used in ADLDS, for those applications using the ADLDS-based LDAP simple bind.

Forgotten Password Reset FIM 2010 provides a Password Reset solution which delivers the following features:

• Users are prompted to register for password reset upon login. They are presented with a series of questions to which they provide their answers.

• Should the user forget their password, they can reset it in one of two ways: o Using the “Reset Password” button on the Windows login screen (making use of locally-

installed client components)

Ser

ver

Com

pone

nts FIM Sync

MAs

SyncDB


Iden

tity

Sto

res

AppDB

FIM PortalNat

ive

Clie

nts

FIM Service

Sync Manager

AD/Exchange

Outlook

AuthZWorkflow

PermissionsRequest Processor

Action Workflow



o Using the web-based password reset portal (for example, on a locked-down kiosk machine in the office, making use of Internet Explorer and ActiveX components)

• When the user attempts to reset their password, they are prompted to answer a sub-set of the questions to which they have registered answers. Provided the answers match the registered answers, the user is then deemed to have authenticated themselves, and they can then set a new password for themselves

• Repeated incorrect attempts to answer the questions result in temporary or permanent lockout from the password reset system. Administrators can lift this lockout in the FIM Portal.

• Unlimited numbers of question sets can be defined, allowing configurations for different languages and different levels of assurance

This password reset system is implemented using the same FIM policies and workflows which we have been considering above – it is not a separate system.

The implementation involves enabling the policies in FIM which control this process (they are pre-configured) and entering the questions to which our users will register answers. For those client machines where we want the users to be able to reset their password from the login screen, we deploy client software in the form of a .MSI package.

Password Reset System Components Primary components of the password reset system are:

• Authentication Workflow: The process which asks questions and confirms the answers is an authentication process, implemented as a workflow which is triggered by a policy which recognises a user’s request to reset their password

• Client components: If the “Reset Password” option is to be made available on the Windows workstation, client components are required which can then communicate with the FIM Service to act as an interface to the authentication process.

• Either as well as, or instead of, the client components, it can be valuable to implement a kiosk computer in a public space in the company which provides Internet Explorer access to the intranet. FIM delivers a web-based solution for password resets which therefore avoids the need to deploy the client components to workstations.

Password Synchronization Components The primary new component for the synchronization of passwords from Active Directory is an agent, the Password Change Notification Service (PCNS), which needs to be installed on all our Domain Controllers. PCNS is configured using some custom objects in the Active Directory configuration partition, which is then replicated throughout the AD system – these custom objects require a schema extension in AD.

Once PCNS is installed, the ILM synchronization service is configured to receive changed passwords from AD, and the ADLDS management agent is configured to forward the changed passwords to the relevant ADLDS account.

Phase 5 Summary We have implemented password reset and synchronization within FIM.

Now our system contains these components:



Phase 6: Certificate Management To improve the security of a variety of systems, we want to make use of certificates. We want to distribute smartcards to our employees as they arrive, and issue authentication certificates with the smartcards.

We want to use the Certificate Services (CS) of FIM to provide solutions to some of the common problems encountered with smartcard management, for example:

• Automated triggering of the process to provision a smartcard with appropriate certificates • Timely renewal of certificates which are about to expire • Provision of temporary cards in case an employee forgets theirs • Revocation of Certificates which are no longer authorized • Suspension/Reinstatement of cards which are temporarily not required

CS Components • The Certificate Services make use of their own separate database, and this is managed using a

dedicated portal. Users will access the portal to participate in the various workflows which can be used for the issue, renewal, blocking and unblocking of certificates and smartcards.

• Permissions governing the workflows in the CS are set directly in Active Directory • So that the details of the certificates which are issued are correctly captured by the CS database, we

implement an “Exit Module” on the Certificate Authority (CA). • Process integration is realised using a Management Agent in the Synchronization Service. This allows

the creation of new workflows in the CS DB, based on events in other connected systems.

Having implemented the CS Components, our system now looks as follows:

Ser

ver

Com

pone

nts FIM Sync

MAs

SyncDB


Iden

tity

Sto

res

AppDB

FIM PortalNat

ive

Clie

nts

FIM Service

Sync Manager

AD/Exchange

Outlook

AuthZWorkflow

PermissionsRequest Processor

Action Workflow

Windows

AuthNWorkflow



Phase 6 Summary We have completed our implementation. The FIM solution is deployed and we have well-managed systems!

Can it really be this easy? We have discussed a simple scenario, and the system components required to implement the scenario. Life is, however, rarely that simple, and in this section we mention some of the complexities which can be expected in a FIM implementation.

Careful Change Management is required As IT professionals, we are all aware of the need for change management. Before any modifications are made to a running system, the changes go through a rigorous system of analysis, approval, testing and documentation. This minimizes the risk of bugs being introduced to the system as a result of the changes. Because of the inter-relationships between the Policies, Workflows, Sync Rules, Classic Code components... and other parts of the FIM implementation, there is a danger that a change to one component to address one issue has an adverse impact on another component. Only by careful design of the components, and adherence to a change management system once the system is in production, can such risks be minimized.

Extensions will often be required FIM provides powerful building blocks for the technical implementation of policy, as well as pre-configured functionality which is reasonably easy to modify to suit a particular scenario.

There are a number of areas, however, where additional components are required, or where the functionality offered by FIM needs significant extension.

While a good deal of functionality can be achieved by building objects and configurations in the UI, many solutions will require some coding. Examples of this are:

• Custom Workflows to support specific approval and validation scenarios • Handling of specific deprovisioning implementations • Initial load configurations where complex data transformation and matching is required to consolidate

data from systems where the data is incompatible



• Password-handling code for systems which do not offer standardised password-handling functionality themselves, and which are therefore not supported out-of-the-box (many are).

• Custom Management Agents for systems not supported out-of-the-box • Custom CA Exit Modules for CAs not supported out-of-the-box

All of these extensions are built in well-documented .NET assemblies, and are nothing to be afraid of: but coding expertise and experience with the FIM extensibility model will be required for successful implementation of these.

Areas where custom solutions are typically required There are some areas where FIM does not pretend to deliver functionality. However, before criticising the product too much, it is worth bearing in mind that it is a v1 product, and that Microsoft has already promised a Feature Pack about 6 months after release, to address some of these issues.

• Reporting: FIM does not deliver out-of-the-box reporting. OCG has SQL Server Reporting Services-based solutions which cover a broad cross-section of reporting requirements, and there are 3rd party solutions available, such as that from bHold.

• Hierarchy: FIM’s database is pre-configured to store objects without a specific hierarchy, and the portal does not have hierarchy-tree display capabilities out-of-the-box. Many implementations of business rules require awareness of a hierarchy, with inheritance of data (usually downwards) and responsibility (usually upwards) across the hierarchy. OCG has fully-integrated extensions to FIM to store, display, and process data according to one or many hierarchies.

• Role-based Access Control: FIM does not claim to implement a full RBAC specification, although a simple implementation of role-based access is possible. Both OCG and 3rd parties, such as bHold, offer integrated role-based solutions.

System Management: Room for Improvement The basic functionality to provide system management is in place. There is a series of components which assist the management of the system:

• PowerShell cmdlets for configuration transport. These allow the extraction of configuration from, say, a development environment, and the import of this configuration into a test or production environment.

• Microsoft System Center Operations Manager. A Management pack exists for SCOM, providing integrated system monitoring

• Sample clients and sample code for data query and extraction

There are enhanced tools which extend the functionality offered out-of-the-box: for example, OCG’s Configuration Manager does not just extract and import system configurations, it packages the configurations and provides version control so that the deployments can be integrated into a change management process with the least difficulty.

There are system management issues which will need to be solved depending on policies in place at the particular client: for example, the period of time for which audit data will be retained, coupled with the amount of base data and the frequency of changes, will affect the extent to which it is necessary to provide archival services. These would move old audit data to a secondary database, so that the audit data is available, but is not present in the production database, so that performance is optimized. The building blocks for archival are present, but the solution will look different for different implementations.



Common challenges with any Identity Management Project Any list of complexities concerning a Forefront project would be incomplete without mentioning the political and organizational issues which are part of any such project. Because identity management is, by its nature, a discipline which addresses issues which cross the boundaries defined by system responsibility, it can involve a good deal of persuasion and sometimes political pressure to get the results which the organization requires.

Often, a shared vocabulary needs to be developed, and used with clarity, so that there is a common understanding. One person might see a “transfer” where another sees a “change department id”, and this can lead to misunderstandings and problems in process implementation.

Similarly, a standard approach to some technical matters is required – for example, character set mappings, date formats, and standard job titles might need to be defined.

In order to achieve these cross-departmental goals, an unusual level of political engagement is required. Many IT projects take place within a department – the department’s staff is implementing or modifying their own system, which handles their own data and their own processes. Identity Management projects rarely have it so easy!

Compatibility with/Upgrade from ILM 2007 It is beyond the scope of this paper to examine in detail the issues surrounding the upgrade of an ILM 2007 system to FIM 2010. However, a few points are worth making:

• An ILM 2007 database can be upgraded by installing FIM 2010 against it. • Generally, all ILM 2007 management agents will work without modification in the FIM2010 sync

engine • Note that the path to the executables (and therefore to configuration files you may use in code) has

changed, so straightforward adjustments may be required • FIM runs on a 64-bit platform where ILM 2007 uses 32-bit platforms. Where client components are

required for connectivity, it is important that they are also available for 64-bit platforms.

Conclusion The innovative policy engine, coupled with the scalability and flexibility of the implementation, mean that FIM is a system which is “done right”. We expect that future enhancements will build on this solid foundation, continuing the integration and further development of features into the portal.

Microsoft has made a bold move forward with FIM, and Oxford Computer Group is proud to be at the leading edge with this new and exciting product.

Forefront Identity Manager fulfils most of the requirements for an Identity Management system. There are gaps – the lack of out-of-the-box reporting is the most obvious – but the product forms a very sound foundation on which to build – and because FIM is built using widely-used Microsoft components, there is a wide variety of solutions to fill these gaps from companies like Oxford Computer Group, and the development of custom solutions is reasonably straightforward.



For Further Information For more information about how Oxford Computer Group can help you evaluate, upgrade, implement or enhance your identity management system, please contact us as follows:

Email: [email protected] Web: www.oxfordcomputergroup.com

UK: Bignell Park Barns, Chesterton, Oxfordshire, OX26 1TD, UK Tel: +44 (0)8456 584425 Fax: +44 (0)8456 584426

US: One Microsoft Way, Building 25, Room 1482, Redmond WA 98052, USA Tel: + 1 877 862 1617

DE: Winterlestr.10b D-85435 Erding, Deutschland Tel: +49 8122 892089-0 Fax: +49 8122 892089-99

BeNeLux: Sweelinckplein 9, (Unit 11), 2517 GK Den Haag, The Netherlands Tel: +31 (0)70 36 21 045 Fax: +31 (0)70 36 21 677

Oxford Computer Group (OCG) is a Microsoft Gold Partner specializing in Identity and Access (IAM) management consulting and training. With operations in the USA, UK and mainland Europe, OCG has an enviable repository of expertise, solution components and training courses. OCG has deployed over 500 IAM solutions and trained over 5000 people on Microsoft IAM technologies. We understand IAM – benefit from our expertise and capability.

Copyright Oxford Computer Group 2010



Appendices

Appendix 1: Detailed function of the Request Processor The Request Processor receives requests via Web Services, and evaluates the other components as appropriate:

• The request processor first establishes which policies apply to the request being processed. This set of policies define the downstream tasks to be executed. This set of policies is the “Applied Policies”.

• Permissions are gathered from all Applied Policies. If each of the changes in the request is covered by at least one permission-granting policy, the request continues to be processed; if not, the request processor returns “Access Denied”.

If the request is only to Read data, rather than to modify it, no further action is undertaken by the Request Processor. The steps below therefore apply to Modify requests. In our example, the request contains the data to “Add a new External Employee”.

• Authentication (AuthN) Workflows are triggered. Each Applied Policy can require additional authentication steps before allowing the request through. This is most commonly applied in the Password Reset workflow, where a user cannot authenticate to Windows, but rather has to answer the pre-registered questions in exactly such an Authentication Workflow. If they answer the questions correctly, they are deemed to have authenticated themselves successfully, and the password reset request continues.

• Authorization (AuthZ) Workflows which have been defined in the Applied Policies are triggered once all Authentication Workflows have successfully completed. These workflows are used to implement a variety of checks to ensure that the request is allowable: the easiest to understand is an approval step where another user is invited to answer “Accept” or “Decline” to a prompt (either in the portal or in Outlook). AuthZ workflows are also used to validate the submitted data, for example against an external source to check for uniqueness or other validity. We will be using an Authorization Workflow to send an email to the InternalSponsor so that they can respond “Accept” or “Decline” to the request to add the new external employee.

• Once the Authorization Workflows have completed successfully the request is carried out – the changes are made in the AppDB.

• Action Workflows are then triggered. These are used where further modifications to data are required, based on the change which has just taken place. Changes can be made to:

o The Request which is being processed o The object representing the user making the request o The object which is the target of the request o Additional objects used to support the synchronization and workflow system



These changes are made in the form of a new request, which in turn might trigger additional workflows. It is common, however, that these changes are committed without the need for further authorization, since they are initiated by the system itself.

We will using be an Action workflow to perform two tasks:

o to generate a random password for the new AD Account and to send this password to the InternalSponsor in an email.

o to add the Synchronization Rule for AD/Exchange to the external employees who have been successfully approved by an Authorization Workflow

Appendix 2: Pre-Configured Functionality The following table lists the key functionality supplied by the FIM portal after a fresh installation.

Pre-Configured User and Group Management Functions Create/Update/Delete User Objects with distinct Administrator and User permissions

Web-based

Create/Update/Delete Group Objects with distinct Administrator and User Permissions

Web-based

Active Directory Group Types and Scopes supported Distribution Lists/Security Groups/Mail-Enabled Security Groups; Domain Local/Global/Universal, including logic to validate memberships for AD-compatibility

Self-Service management of groups via “My Groups” Create/Update/Delete group objects. Web-based. Users can add themselves to groups, and modify memberships of groups where permissions are

Web-based or in Outlook

Approval workflow for changes to memberships in groups which have an Owner

Web-based or in Outlook

Automatic group memberships based on filters “Forgotten Password” reset portal Windows-based pre-login or web kiosk-based Time-based groups E.g. “Users who will leave the company in the next 4 weeks”

It is worth pointing out that in keeping with Microsoft’s policy that a system must be secure in its post-installation state, most of the policies which govern this functionality are disabled, and must therefore be selectively enabled to make the functionality available.

Microsoft Forefront Identity Manager 2010

Documents

Transcript of Microsoft Forefront Identity Manager 2010