Wednesday, May 13, 2015

What is Forefront Identity Manager?

After you have read our introduction article, you will have a good understanding of what exactly Identity Management is and what benefits a good implementation of an Identity Management system can have for a company. In this article, we’ll be focusing on the Identity Management system that these series of articles will be all about, which is Forefront Identity Manager 2010 which we, from now on, will be referring to as FIM 2010. The key takeaways of this article are to get a good understanding of the evolution and the architecture of FIM 2010. In addition, as we stated in the introduction article, this all based on FIM 2010 and we will cover all new features and improvement inside the R2 release in separate article.

The evolution of FIM 2010

A good method to get understanding of the capabilities of a software platform in general is to first look at its predecessors. Looking at the name, FIM 2010, you might think that it evolved from something like FIM 2009 or FIM 2008. Unfortunately, it is less obvious and a little bit more complex.
Over 10 years ago, Microsoft acquired Zoomit Via and turned that into a product called MMS (Microsoft Metadirectory Services). This product was offered for free by Microsoft with the advice to always hire Microsoft Consulting Services to do the actual implementation. Using MMS, it was possible to connect different directory services and perform a basic synchronization of objects and attributes.
The next big step was the introduction of Microsoft Identity Integration Server 2003 (MIIS). MIIS 2003 was rebuild from scratch completely. But although no original MMS source resides in MISS, MIIS was built on the ideas behind MMS. MIIS also started the support of .NET framework integration for the first time, which enabled customizations to the product using APIs.
For the next step in the evolution, Microsoft acquired a company that offered the product IdNexus. Idnexus was capable of managing X.509 certificates and smartcards. Microsoft renamed this product into Certificate Lifecycle Manager (CLM), integrated this into MIIS 2003 and thereby introducing Identity Lifecycle Manager (ILM) 2007. Therefore, ILM 2007 is actually a merge of both MIIS 2003 and CLM.
With ILM 2007, a stable synchronization engine was introduced that was also capable of managing certificates and smartcards. However, as we have learned in the introduction article, Identity Management is more than a synchronization engine. Microsoft soon realizes this and puts in a great amount of effort to build a complete platform on top of ILM 2007 to create a platform that satisfies all of today’s needs on Identity Management. To accomplish this, In 2010 Microsoft releases Forefront Identity Manager (FIM) 2010. FIM 2010 consists of the MIIS 2003 / ILM 2007 synchronization engine and additional features like, self-service portal, self-service password reset and codeless provisioning. With the introduction of FIM 2010, Microsoft also stops the support for the x86 platform as FIM 2010 is only available in a 64-bit version. So the FIM Sync Service (which we’ll talk about in a bit) can be thought of as the x64 version of the MIIS / ILM synchronization engine. With the release of FIM 2010 (and R2 being the latest release) Microsoft creates a complete Identity Management platform that not only serves the need of synchronization, but also adds great capabilities regarding self-service and many forms of extensibility.
Now that we’ve looked at the predecessors of FIM 2010 we have a clear view on how FIM 2010 evolved in the product that it is today. In the second part of this article, we will start to explore FIM 2010 by looking at the architecture, the different roles and its extensibilities.

The FIM Architecture

What better way to start explanation of the FIM 2010 architecture then by referencing the official Infrastructure Planning and Design (IPD) guide on Forefront Identity Manager 2010. Figure 2.1 below shows the complete architecture of FIM 2010, taken from version 1.0 of the Microsoft’s IPD. The full IPD can be downloaded free of charge here http://technet.microsoft.com/en-us/library/ff630889.aspx. We recommend anyone to explore the most recent IPD before implementing any Microsoft product in general. The IPD’s help clarify and streamline design processes for Microsoft infrastructure technologies, with each guide addressing a specific infrastructure technology or scenario.
Figure 2.1 FIM Synchronization Service
We will start our architecture walkthrough by explaining the part evolved from ILM 2007, the FIM Sync Service. We will continue by looking at the FIM Service and FIM Portal, which are brand new. We will finish of by talking about the different FIM Add-ins and extensions that come with FIM 2010. We will discuss the FIM Certificate Management in a high overview only because, as explained in the introduction, there is no focus on FIM certificate management in these series as we feel it is a very different subject and usually implemented separately.

FIM Synchronization Service

The FIM Synchronization Service (short FIM Service) can be considered the heart of the FIM 2010 platform. As explained before, the FIM Sync service is inherited from ILM 2007 and is basically the x64 version of the ILM 2007 Sync service. The FIM Sync Service contains a series of different components. First the FIM Sync Service database. This database is hosted on a Microsoft SQL Server instance preferable the latest which, at this point, is SQL Server 2012. The database contains all objects and attributes of the identities and also contains the management agent configurations split into different Connector Spaces and a MetaVerse (two terms that we will cover further on). Then there is the FIM Sync Service itself which is basically a Windows Service running under a (preferably Active Directory) service account that is responsible for the actual synchronization process between FIM and the different external systems. The FIM Sync Service is able to communicate with external system using a set of different Management Agents, which are also a component of the FIM Sync Service. The last component is the FIM Password Change Notification Service (PCNS), which is responsible for synchronizing password changes that occur on Active Directory to other external systems that are connected to FIM. This requires the installing of a FIM PCNS service on every domain controller in the Active Directory Forest.
 Figure 2.2 FIM Synchronization Service
Before addressing the next set of components of the architecture (the FIM Service), it’s important to understand how FIM Sync is built up. We’ll do this by representing the FIM Service as Microsoft does this on TechNet, the “donut-shape”.
Figure 2.3 FIM Sync “the donut”
Figure 2.3 shows above, clearly shows how FIM Sync connects the external systems together. An external system that FIM Sync communicates with (in other words provisions) is always connected to FIM Sync using a Management Agent (MA). Let’s take Active Directory as an example here. The Active Directory Management Agent (ADMA) is used to connect to the Active Directory Forest or domain. The ADMA maintains objects and attributes of the external system inside it’s Connector Space (CS). The CS can be thought of as a snapshot of (part of) the Active Directory. Inside the ADMA you define, amongst some other details that we’ll get into later in these series, the name of the forest to connect to, the different OU’s to connect to and the objects and attributes you want to synchronize to the CS. Another example of an external system could be a HRM system. The same way as with Active Directory, the FIM Sync Service uses a Management Agent to provision objects to and from the HR Connector Space. To be able to actually synchronize objects from one external system to the other FIM needs to join objects of different Connector Spaces together to one identity that contains a merge of the attributes of all the related external systems. The FIM Sync Service does this by making use of what is called the MetaVerse. The MetaVerse is the identity store that FIM Sync uses to merge attributes of objects from different connector spaces into one identity.
The third external system that we see in figure 2.3 is the FIM Service. The FIM Service is a new component (not included in ILM 2007) and is, amongst other things, used to create extended synchronization rules and different types of workflows. Later on in this article we’ll discuss the FIM Service in more detail and we’ll see that the FIM Service is actually maintained using the FIM Portal. For now it’s enough to understand that the FIM Service is nothing more than an external system that communicates with the FIM Sync using a MA and a CS just as any other external system would.

FIM Service and FIM Portal

Now that we discussed the FIM Sync and understand, what is does in basic it’s time to take a more detailed look at the FIM Service. In the previous section, we learned that the FIM Service is actually nothing more than just another external system seen from the FIM Sync point of view. But, what exactly is the function of the FIM Service?
Figure 2.4 FIM Service
In figure 2.3 zooms in on the architecture of the FIM Service and all the other components that it can communicate with. First of all, the FIM Service uses a database which is hosted on a Microsoft SQL Server instance preferable the latest which, at this point, is SQL Server 2008 R2. The database contains all objects that the FIM Service uses which are in fact created using the FIM Portal. The most important function of the FIM Service is to actually extend the synchronization that the FIM Sync performs. The FIM Sync can be used to define very complex authorization, authentication and action workflows that, combined with Sets and Management Policies Rules, are able to run Extended Synchronization Rules that will be used by the FIM Sync during the actual synchronization. The FIM Service is one of the FIM Extensibilities that make FIM 2010 very flexible. Later on in this article, we will see that there are many more FIM Extensibilities. To be able to actually create and define all the objects, the FIM Sync uses a Graphical Interface (GUI) which is provided by default in FIM 2010. The FIM Portal is the GUI that is used to configure the FIM Portal. As can be seen in figure 2.3 the FIM Portal is based on Windows SharePoint Services (WSS). To be more precise it uses WSS 3.0 SP2. As we’ve learned the FIM Service is an external system to the FIM Sync. So does the FIM Service also contain objects like users and groups? Correct. In fact, these objects can also be maintained, even on a delegation of control basis, using the FIM portal. The FIM Portal is also the base for delivering the Self-Service options that we’ve seen earlier. The FIM Password Reset Portal, also based on WSS, is the last component that communicates with FIM Sync and is used to provide users the ability to reset passwords , which is a big part of the Self-Service strategy.

FIM Add-ins and Extensions

The next set of components in the architecture is the FIM Add-ins and its extensions as shown in figure 2.4. We’ll discuss the components that make up the Add-ins one by one in more detail. The first one is the FIM Add-in for Outlook. This is a client component that can integrate with Outlook 2007 and communicates with Exchange 2007 or 2010 using MAPI calls. Using the Add-In, end-users are able to request access to a new authorization group without even having to open the FIM Portal. Using the FIM Add-in, workflows created in the FIM Portal, can be configured to send approval e-mails to managers to let them approve or decline a specific workflow. With the FIM Add-in for Outlook manager can perform the approve or decline using a single click.
Figure 2.5 FIM Add-ins and Extensions
The second part is the FIM password and authentication client service. And the last part is the FIM Password and Authentication Extension. This extension can be used on clients using Windows XP, Vista or Windows 7. When the extension is installed an option to request a password reset is integrated in login screen of the clients operating system. The first time a user logs in after the password reset extension has been installed, the users will be prompted with some security questions that he has to answer once. In the event that he wants his password to be reset, he will be prompted with the questions for which he entered the answer earlier and is, if he answers them correctly, able to request a password reset without having to contact a helpdesk or support desk.

FIM Certificate Management

The last piece in the FIM Architecture puzzle is FIM Certificate Management (CM). We mentioned earlier that we would not be covering FIM CM in these series in detail, so we’ll quickly go through the basics. As you might recall from the beginning of this article Certificate Management was brought into ILM 2007 and also became part of FIM2010. Basically FIM CM is just another external system just like i.e. Active Directory or the FIM Service. Therefore, the FIM CM has its own Management Agent with a corresponding Connector Space. The FIM CM is used to managed user certificates and to accomplish this it communicates with Active Directory as well. Figure 2.5 shows the architecture in details.

Figure 2.6 FIM Certificate Management

FIM Extensibilities

As we mentioned earlier FIM 2010 provides extensibilities options in many areas, this is part of what FIM 2010 makes very flexible. In this section, we look at all the different extensibility areas that FIM provides. The figure below shows the FIM Architecture laid out in a way that so that the different areas are easy to point out.
Figure 2.6FIM Extensibilities
  1. Using PowerShell cmdlets Create, Read, Update, Delete, and Enumerate operations can be performed on the FIM Service helpful for performing imports and exports in migration scenarios. A complete guide on all the cmdlets and examples on how to use them go beyond the scope of these series but can easily be access on technet here:http://technet.microsoft.com/en-us/library/ee534906(WS.10).aspx
  2. The Portal, as we learned based on WSS, is the GUI that can be used to manage objects and attributes. This GUI is fully customizable when it comes to configuring who (what group) sees what (which objects and attributes) in what way (layout). Being able to modify the schema that is used by FIM Service is also part of the extensibility.
  3. The password reset that can be integrated on a client workstation is an example of customization on the windows platform.
  4. The webservices API enabled you to build your own webservice client which would for example enable you to fully replace the FIM Portal or integrate it into an existing portal.
  5. The schema that FIM uses can be altered as well. Using XML you are able to modify the exiting schema by adding, changing or removing existing attributes of object or even create new objects as well.
  6. Activities that are used to identify a user making a particular request is called a authentication workflow. These can be created using the FIM Portal
  7. An example of an authorization workflow is the Approval workflow that we mentioned earlier. To create new or extend existing approval workflows authorization workflows can be used.
  8. An example of an action workflow is adding a synchronization rule to an userobject, which in turn will be used by FIM Sync to do provisioning based on the configuration in that syncrule. Another example of an action workflow can be a notification (i.e. via e-mail).
  9. The last form of customization is inside the FIM Sync. As we talked about earlier FIM Sync uses management agent to communicate with other external system. Out of the box FIM 2010 contains several management agents. Using the Extensible Connectivity Management Agent (ECMA) it is possible to create your own Management Agent for a particular external system that you cannot connect with using one of the default management agents.

Default Management Agents

As we saw in the FIM Extensibilities section FIM 2010 contains several Management Agents out the box to communicate with different types of external systems. Currently FIM 2010 Update 1 comes with Management Agents for the External Systems show in table 2.1 below. This list is of course subject to change. For the most up to date list, we refer to http://technet.microsoft.com/en-us/library/ff608275(WS.10).aspx.
Management Agent NameVersions Supported
Active Directory Domain ServicesActive Directory 2000, 2003, 2003 R2, 2008, 2008 R2
Active Directory Lightweight Directory Services (ADLDS)Active Directory Lightweight Directory Services (ADLDS)
Active Directory Global Address List (GAL)Active Directory Global Address List (GAL) – Exchange 2000, 2003, 2007, 2010
Attribute-Value Pair text fileAttribute-value pair text files
FIM Certificate ManagementForefront Identity Manager 2010 Certificate Management
Delimited text fileDelimited text files
Directory Services Mark-up Language (DSML)Directory Services Markup Language (DSML) 2.0
Extensible ConnectivityAny call-based or file-based data source
Fixed-Width text fileFixed-width text files
FIM ServiceForefront Identity Manager 2010
IBM DB2 Universal Database
  • IBM DB2 version 9.1 or 9.5
Support Client versions:
  • IBM DB2 OLEDB v9.5 FP5
  • IBM DB2 OLEDB v9.7 FP1
IBM Directory ServerIBM Tivoli Directory Server 6.0 or 6.2
LDAP Data Interchange Format (LDIF)LDAP Data Interchange Format (LDIF)
Lotus NotesLotus Notes Release v6.5 or v7.0
Novell eDirectoryNovell eDirectory version 8.7.3 or 8.8.5
Oracle DatabaseOracle Database 10g, 11g
SAP R/3
  • R/3 Enterprise (4.7)
  • mySAP 2004 (ECC 5.0)
Microsoft SQL ServerSQL Server 2000, 2005, 2008
Sun and Netscape Directory ServersSun Directory Server 5.x and 6.x
Original:

ADFS with Office 365 Step by Step Install Guide

In this step by step guide, we’ll walk you through configuring Active Directory Federation Services (AD FS) for use with Office 365.  In this first document we’ll just install a single server.  Later we’ll show you how to introduce an AD FS Proxy Server and redundancy.

Add your Domain to your Office 365 Account

Since we are starting from the very beginning.  The first thing you’ll have to do is sign into your Office 365 account and go into the Domains area.  Click the Add a domain link to add your domain.
image
Enter the domain that you want to Federate and click the Check Domain button.
image
You will then be asked to confirm the domain details.  If everything is correct, click Next.
image
Finally you be given instructions on how to create a TXT record in your Internet DNS.  The TXT record is Microsoft’s way of verifying that you own the domain and creating this record does not impact any existing services.  After you create the TXT record in DNS you must return to the Office 365 Administraton site and verify the domain by clicking the Verify button.
image

Install AD FS

Now that your domain has been added and verified, we can move on to installing AD FS in your local Active Directory.  The big requirements for this step are:
  • Your Active Directory Domain must be in Windows 2003 mixed or native mode.
  • You must have a Windows Server 2008 or Windows Server 2008 R2 to install AD FS on.
You must first download AD FS 2.0 from:
When you launch the install program, click Next.
image
Accept the license and click Next.
image
On the Server Role screen, choose Federation Server and click Next.
image
The wizard will automatically install the required prerequisites.  Click Next to begin the installation.
image
When the installation is complete,  uncheck “Start the AD FS 2.0…..” and click the Finish button.  The reason we are unchecking that box is IIS was installed as part of the prerequisites and we now need to use IIS to request a certificate.
image

Obtain a Certificate for use with AD FS

In this example, we’ll request a certifcate from a public certification authority.  Unless you already have a certificate infrastructure deployed, it’s probably best to puchase a certificate instead of generating your own.  Trust us on this one, just spend the money on a certificate, it will save you a lot of time.
On the server you just installed AD FS on, open IIS Manager and click on Server Certificates.
image
Then click on Create Certificate Request
image
In this example we’ll be requesting a wildcard certificate.  A wildcard cerficate is not necessary, but we plan on using this same cerificate for Exchange rich coexistence.  The important field is the Common Name field.  In the image below, you can see it’s *.domain.com.  In most cases (where you want external users on the Internet to be able to authenticate) Domain.com must be your external domain name.  If you were are not requesting a wildcard cert the name would something like fs.domain.com, or adfs.domain.com.
image
On the next screen, ensure the Bit Length is at least 2048 and click Next.
image
Finally, specify a file name for the certificate request and click Finish.
image
You must now take the request to a public certification authority such as GoDaddy or Verisign.  When the request has been processed, they will provide you with a Certificate.

Importing the Certificate

After the certificate request has been processed, you’ll need to import the certificate.  To do that through IIS, you must go back to the Server Certificates and click Complete Certificate Request:
image
Browse to the Certificate file and enter the friendly name.  In this example a wildcard cerficate was used, so the friendly name will be *.domain.com.  If you used a different name, such as fs.domain.com or adfs.domain.com, you’d enter that name here as well.
image
After the certificate has been imported, you’ll want to verify it by going back to Server Certificates in IIS.
image
Next, you’ll need to add the Certificate to the Default Web Site.  With the Default Web Site Selcted click Bindings.
image
Click Add
image
Choose Type https, IP addresss All Unassigned, and Port 443.  Then select the newly imported certificate and click Ok.
image
The site bindings should now look like:

image

Configuring AD FS

Now that we have the cerficate installed, we can resume the AD FS configuration. To launch the AD FS configuration wizard, just go into Administrative Tools and click on AD FS 2.0 Management.
image
When the AD FS Management Console opens, click the AD FS 2.0 Federation Server Configuration Wizard Link.
image
Select the option to Create a new Federation Service
image
On the next screen select New federation server farm.  Choose this option unless you are absolutely sure you’ll never be installing a second AD FS server.  It doesn’t hurt anything to have farm with only a single server, but it might give you more options down the road if you want to add redundancy.
image
On the Federation Service name, choose the certificate to use.  In this example a wildcard certificate was used, so the name must be specified, fs.domain.com.  This is the name clients will connect to, so it must be resolvable via DNS both internally and externally.
image
You must then specify a Service Account in Active Directory that will be used by AD FS.
image
On the Summary Screen review the changes that will be made and click next to begin the configuration.
image
When the installation is complete, click Close.
image

Install and Configure the Office 365 PowerShell Module

The next step is to download the PowerShell module and configure the Trust with Office 365.  The PowerShell Module comes in 2 versions.
After the tool has been downloaded, run through the installation wizard.

Install the Sign-In Assistant

The Sign-In Assistant must be installed next.  It comes in 32 and 64 bit versions.
Launch the Sign-In Assistant installer and click the Install button.
image
When the installation is complete, click Finish.
image

Set up the Trust with Office 365

We must now open PowerShell to convert the domain we previously added to Office 365 to a Federated domain.  You’ll want to run Microsoft Online PowerShell as Administrator.
image
Type $cred=Get-Credential and hit Enter.  This cmdlet prompts you for credentials. Type your Office 365 administration account credentials.
Type the following and hit enter:
Connect-MsolService –Credential $cred
Type the following, where domain is the name of your domain and hit enter:
Convert-MsolDomainToFederated –DomainName domain.com
If successful, you should see the message:
Successfully updated ‘domain.com’ domain.

Enable Directory Synchronization

Now that the AD FS server is set up we are ready to enable Directory Synchronization.  Before you begin you should make sure the following requirements are met.
  • You have a 32 bit Windows 2003 or 2008 Server to install Dir Sync on.
  • The server cannot be a domain controller, but must be a member of the domain.
  • You must have an account which has Enterprise Admin rights to the local Active Directory.
  • .Net 3.5 or later and PowerShell
You’ll need to start the Directory Sync configuration in the Portal by click on Users (under Management in the left column).  Once there, click on Set up Active Directory Synchronization.
image
Work through the checklist and on Step 3, click Activate and then in Step 4, download the client.
image
Run DirSync.exe and click the Next button on the welcome screen.
image
Accept the License Terms and Click Next.
image
Choose the installation folder and click Next to begin the installation.
image
When the installation is complete, click Next.  Verify the “Start Configuration Wizard now” box is checked and click Finish.
image
When the configuration wizard appears, click Next on the welcome screen
image
Enter your Office 365 Administrator Credentials and click Next.
image
Enter the username and password for local Active Directory Enterprise Admin and click Next.
image
If you plan on using Rich Coexistence, check the Enable rich coexistence box.  In this example the option is not available because there is not an Exchange 2010 Server.  Click Next to begin the configuration.
image
When Complete, click the Finish button to begin the initial synchronization.
When the directory synchronization is running check the events in the Application Event log to see the current status.

Testing AD FS

At this point we should be ready to do some basic AD FS testing.  The first thing you’ll probably need to do is create an account in your local Active Directory (without a mailbox if you have Exchange).  You’ll need to make sure the account’s UPN suffix is @domain.com.  If your Internal Active Directory Namespace is something like domain.local, or anything other than domain.com, you’ll probably have to add an additoinal DNS suffix to the domain so you can assign it to users.  See the following article for more details:
Once the account is created, let it replicate into Office 365 and then assign it a license.
Before we can try and sign in there are a couple more things that need to be done on the workstation you’ll be testing from.
First, Sign-In Assistant must be installed.  It comes in 32 and 64 bit versions.
Download and install the appropriate version.
Second, you’ll probably need to modify your Internet Explorer settings so you can automatically authenticate with the AD FS server.  The default settings in IE seem to be that Automatic Login occurs only in the Intranet Zone.
image
So to keep things simple we just need to put our AD FS server in the Intranet Zone.  This will allow Internet Explorer to automatically pass the user’s credentials to the AD FS server.
image
Finally, sign into the workstation as the test account and browse to https://portal.microsoftonline.comwhen prompted for the user name enter user@domain.com, or in this exampletestuser2@office365demo.com.  When you enter the user name, you’ll notice the Password Area turns grey and you must click the link to Sign in.
When you click the link pay close attention to the Address bar in your browser, what you should see happen is your client connecting to your AD FS server, for example fs.domain.com.  If you get prompted for credentials, you should check your Internet Explorer settings, if you get a page cannot be displayed, check your DNS to make sure the client can resolve the AD FS server.
If all goes well you’ll be automatically logged into the Portal.
At this point, you should have a very basic AD FS install complete.  Reveiw our other articles for more advanced configuration options.