Configuring SharePoint 2013 for the Forefront Identity Manager 2010 R2 Service Pack 1 Portal

Print | posted on Sunday, February 17, 2013 5:05 AM

Recently Service Pack 1 for Forefront Identity Manger (FIM) 2010 R2 shipped. For IdM heads, this is really good news. Along with a bunch of interesting updates and new bits and bobs it is now possible to run FIM on Windows Server 2012 and also to run the FIM Portal component on SharePoint 2013.

This article discusses why this is important in a FIM deployment along with the key design considerations. We will also cover how to prepare SharePoint 2013 for the deployment of the FIM Portal, and finally the installation of the Portal itself.

Introduction

This article assumes that you are familiar with the functional decomposition of the FIM product and its logical architecture components. This post is not intended to introduce those concepts and therefore is intended for FIM practitioners more so than SharePoint professionals new to FIM. We will be focusing almost exclusively on the FIM Service and Portal components in this article and not talking to the FIM Sync service, Reporting or Certificate Management.

As we know the FIM Portal is based upon SharePoint and installs into an existing site collection, thus SharePoint is a pre-requisite for the FIM Portal. However there are a number of configuration aspects which must be present and correct, and these differ significantly from what would be considered SharePoint “best practices” and in some cases supported SharePoint configuration. In addition there are a number of security and availability considerations.

Why SharePoint 2013?

The FIM Portal is a good example of a composite application built upon SharePoint. For many years this approach was promoted by Microsoft and leveraged across many products. Instead of the FIM team building out their own hosting infrastructure and site plumbing, they built a bunch of customizations on top of SharePoint.

However in the journey to the cloud this model is effectively being deprecated in favour of the loosely coupled, off box approach to customization (a.k.a. SharePoint Apps). Of course aligning such disparate strategy across wildly different release cycles is impossible, and it’s both unfeasible and unnecessary for the FIM Portal to be re-implemented at this stage in line with the new world order.

The harsh reality is that SharePoint 2013 in and of itself offers no value whatsoever in terms of functionality for the FIM Portal. Sure some may argue it can leverage infrastructure improvements, but such arguments are tenuous at best. The FIM Portal works perfectly well today in SharePoint 2010, and needs none of the new end user capabilities, or shudder at the thought, a Modern UI.

So if not functional reasons, why should we care about SharePoint 2013? Why not just continue to run on SharePoint 2010. After all there’s no point making things more complicated than necessary, right? It all comes down to one thing, and that is Windows Server 2012.

FIM 2010 R2 SP1 introduces support for Windows Server 2012, and this is something we definitely want to leverage for our Identity Management platform. The problem is however that SharePoint 2010 doesn’t run on Windows Server 2012 yet, for that we need to wait for SharePoint 2010 Service Pack 2. Whilst coming soon, those building IdM solutions now face either a mix of host operating systems for the various FIM components, or a move to SharePoint 2013.

In essence it’s not a big deal - a basic SharePoint deployment is reasonably straightforward in the grand scheme of things, and in comparison to building out a scalable, available and secure IdM platform its toy computers. The flies in the ointment are a couple of pretty common SharePoint traits.

Firstly SharePoint’s overall addressing architecture along with some shockingly bad deployment guidance which focuses primarily on small scale, often single server deployments. Thus farm deployment aspects are generally not well understood by FIM practitioners which leads to a number of common deployment and operational challenges. Indeed the FIM documentation strongly suggests a “stand alone” installation of SharePoint is best, as it insulates the practitioner from a lot of the deployment steps.

Second are the various things that SharePoint 2013 does or promotes which FIM doesn't like. The best example of this is that the FIM Portal requires the use of Classic Authentication mode (which is deprecated in SharePoint 2013).

You get the picture. These two traits make something that should be straightforward a bit more “interesting”. These “interesting” configuration elements are really the meat of this article, along with a few other recommendations.

Guess what? Yup, you got it. TechNet leaves a lot to be desired here (which is unusual for FIM documentation) including errors in scripts and so on, so this article represents a tested, repeatable and reliable cheat sheet for deployment of the FIM Portal on SharePoint 2013.

Base Platform and installing SharePoint

Our intention is to first deploy and configure the SharePoint 2013 elements required for hosting the FIM Portal. To keep things simple, the FIM Service and FIM Portal components will run on the same machines.

Of course we need Active Directory Domain Controllers, Exchange Servers and SQL Servers in our environment. There will also be a separate machine hosting the FIM Sync service. All of these are assumed to be in place, and are not covered in this article.

There’s not much point deploying an IdM platform without following fundamental Information Security principals. Deploying an insecure or unavailable IdM solution is perhaps one of the most comedic ironies in the Microsoft IT space. As such we will be load balancing our FIM Service and Portal components using Windows Network Load Balancing (NLB). We will also deploy in a least privilege manner, ensuring recommended account restrictions are in place.

First things first, we need our FIM service accounts. This is covered extensively elsewhere and should be familiar to you. However the accounts guidance for SharePoint as it relates to FIM is weak. As we will be configuring Kerberos Delegation later on it’s also critical to have these mapped out. Our domain is corp.contoso.com and the accounts we will be using are as follows.

For the FIM Service account we will also apply the following User Rights Assignments on each machine which runs the FIM Service:

• Deny logon as batch job
• Deny logon locally
• Deny access to this computer from the network

We of course also need some DNS entries, the A records we create should all point to the Virtual IP Address of the NLB Cluster:

• fimservice.corp.contoso.com    (FIM Service)
• fimportal.corp.contoso.com      (FIM Portal)
• fimspca.corp.contoso.com        (SharePoint Central Administration)

We also need three Web Server SSL certificates for the various services, and these should be installed in the Local Computer store on each machine that is hosting the FIM Service and Portal:

• CN=fimservice.corp.contoso.com
• CN=fimportal.corp.contoso.com
• CN=fimspca.corp.contoso.com

The general idea is to build a small dedicated SharePoint instance purely for the purposes of hosting the FIM Portal and nothing else (although it could also host the Password Registration and Reset web sites). It’s a good thing the FIM installer doesn’t provision SharePoint for us, as it gives us maximum control. As many FIM people are not well versed in SharePoint there are many deployments which include a bunch of unnecessary goop, resulting in post deployment guidance such as disabling search indexing! We will avoid such considerations by simply not deploying the Search Service Application (or anything else we don’t need). This will also mean our FIM Portal deployment minimizes the attack surface available.

We need a Windows Server 2012 base image with the SharePoint 2013 pre-requisites installed, and then an installation of the free SharePoint Foundation 2013. Unless we are planning to use this as a shared SharePoint install for other purposes (we definitely shouldn’t be doing that!) there is absolutely no point deploying SharePoint Server.

We need to ensure that we do NOT select the Standalone Server Type. This is evil, pure and simple. Embedded SQL and a craptastic demoware default configuration which will provision a bunch of stuff we don’t want. Also this of course will restrict us to a single server for the portal. So we choose the Complete Server Type. We also should ensure we uncheck the Run the SharePoint Products Configuration Wizard now checkbox at the end of the install, as we are going to use Windows PowerShell for the Farm configuration.

We will also configure a SQL Alias pointing to our SQL Server deployment. This provides us with maximum flexibility and better supports HA and DR for the database tier. Our SQL Alias is named SQLFIM.

This represents our base image. Unfortunately we cannot deploy the FIM bits without configuring the Service and Portal, which requires a SharePoint Farm, so this is the best point at which to create a syspreped or VM snapshot to use for each machine.

We are now ready to create and configure our SharePoint Farm. We will implement SSL for the Central Administration web site. The following Windows PowerShell script will perform the necessary work on the first server in the farm.

Note the naming convention used for the Configuration and Central Administration Content Databases. This keeps the names consistent with those used by the FIM components. Note also that we need to fix up the IIS binding and Internal URL for Central Administration after its creation. This is necessary due to the inadequate implementation of the New-SPCentralAdministration cmdlet and the way in which SharePoint deals with addressing (badly).

<#
    1. FIM Farm Creation.ps1

    Creates a new SharePoint Farm
    Creates Central Administration on Port 443

    Update initial variables as needed to reflect your environment
    Script will prompt for the password of the farm account
#>
asnp Microsoft.SharePoint.PowerShell

$databaseServer = "SQLFIM"
$configDatabase = "FIMSP_Config"
$adminContentDB = "FIMSP_Content_Admin"
$passphrase = "Password1"
$farmAccountName = "CORP\fimspfarm"
$caUrl = "https://fimspca.corp.contoso.com"
  
$farmAccount = Get-Credential $farmAccountName
$passphrase = (ConvertTo-SecureString $passphrase -AsPlainText -force)

Write-Host "Creating Configuration Database and Central Admin Content Database..."
New-SPConfigurationDatabase -DatabaseServer $databaseServer -DatabaseName $configDatabase `
    -AdministrationContentDatabaseName $adminContentDB `
    -Passphrase $passphrase -FarmCredentials $farmAccount
    
$spfarm = Get-SPFarm -ErrorAction SilentlyContinue -ErrorVariable err        
if ($spfarm -eq $null -or $err) {
   throw "Unable to verify farm creation."
}


Write-Host "ACLing SharePoint Resources..."
Initialize-SPResourceSecurity
Write-Host "Installing Services ..."
Install-SPService   
Write-Host "Installing Features..."
Install-SPFeature -AllExistingFeatures

Write-Host "Creating Central Administration..."              
New-SPCentralAdministration -Port 443 -WindowsAuthProvider NTLM
Write-Host "Fixing CA IIS binding..."
Set-SPCentralAdministration -Port 443 -Confirm:$false
Write-Host "Fixing Internal URL..."
Set-SPAlternateURL -Identity "https://$env:COMPUTERNAME" -Url $caUrl

Write-Host "Installing Help..."
Install-SPHelpCollection -All        
Write-Host "Installing Application Content..."
Install-SPApplicationContent

Write-Host "Farm Creation Done!"

Next we need to apply a SSL Certificate to the IIS binding for Central Administration.

For step by step instructions for this, please refer to Using SSL for Central Administration with SharePoint 2013.

On the other server(s) in our farm, the following Windows PowerShell is needed to join the farm:

<#
    1a. FIM Join Farm.ps1

    Joins an existing SharePoint Farm

    Update initial variables as needed to reflect your environment

#>
asnp Microsoft.SharePoint.PowerShell
$dbServer = "SQLSP01"
$configDbName = "ContosoFarm_Config"
$passphrase = "Password1"

$databaseServer = "SQLFIM"
$configDatabase = "FIMSP_Config"
$passphrase = "Password1"

Write-Host "Joining Farm..."
Connect-SPConfigurationDatabase -DatabaseServer $databaseServer -DatabaseName $configDbName -Passphrase (ConvertTo-SecureString $passphrase -AsPlainText -Force)
Install-SPHelpCollection -All
Initialize-SPResourceSecurity
Install-SPService
Install-SPFeature -AllExistingFeatures

Write-Host "Farm Join Complete!"

If we wish to load balance Central Administration we would simply start it’s service instance:

<#
    1b. Start CA.ps1

    
    spence@harbar.net
    03 January 2013
    
#>
asnp Microsoft.SharePoint.PowerShell

# Start the CA Service Instance
Write-Host "Starting Central Administration..."
Get-SPServiceInstance | where { $_.TypeName -eq "Central Administration"} | Start-SPServiceInstance

Write-Host "Central Administration done!"

and apply the SSL Certificate to the IIS binding on each server we run the above.

Now we have our base SharePoint Farm, we should start a couple of Service Applications (SAs): State and Usage and Health Data Collection. These are not “real” SAs in so much as there is no endpoint in IIS, however they should be considered Core SAs in any SharePoint deployment. Usage and Health Data Collection Services is especially important from an operational service management perspective.

The following Windows PowerShell provisions these service applications, we use the same naming convention for the related databases.

<#
    2. FIM Core Services.ps1

    
    Starts the Service Instances for and creates Service Applications and Proxies:
        State Service
        Usage and Health Data Collection Service
        
    Update initial variables as needed to reflect your environment

    
    spence@harbar.net
    03 January 2013
    
#>
asnp Microsoft.SharePoint.PowerShell


## UPDATE THESE VARS ##

# Service Application and DB names
$stateName = "State Service"
$stateDBName = "FIMSP_StateService"

$usageName = "Usage and Health Data Collection Service"
$usageDBName = "FIMSP_Usage"

## END VARS ##




# Create State Service Application and Proxy, add to Proxy Group
Write-Host "Creating $stateName Application and Proxy..."
$stateDB = New-SPStateServiceDatabase -Name $stateDBName
$state = New-SPStateServiceApplication -Name $stateName -Database $stateDB
$proxy = New-SPStateServiceApplicationProxy -Name "$stateName Proxy" -ServiceApplication $state -DefaultProxyGroup


# Create Usage Service Application and Proxy, add to Proxy Group, and provision it's Proxy
Write-Host "Creating $usageName Application and Proxy..."
$serviceInstance = Get-SPUsageService
New-SPUsageApplication -Name $usageName -DatabaseName $usageDBName -UsageService $serviceInstance
$proxy = Get-SPServiceApplicationProxy | ? { $_.TypeName -eq "Usage and Health Data Collection Proxy" }
$proxy.Provision();


Write-Host "FIM SP Core Services done!"

That’s it. We don’t need any other service applications. They won’t be used, so there is no point deploying them and wasting resources.

Next up we need a Web Application and Site Collection to host the FIM Portal. This is where things get a little “interesting”. We create an SSL Web Application in Classic Authentication mode and then a Site Collection using the Blank Site Template.

We also need to configure a number of settings that FIM expects. If we don’t do these things the FIM Portal installer will refuse to deploy. The following Windows PowerShell does the work.

<#
    3. FIM Web Application.ps1

    Creates a new Managed Account
    Creates a new classic mode SSL Web Application in a new Application Pool
    Creates a root Site Collection using the blank site template
    

    Update initial variables as needed to reflect your environment
    Script will prompt for the password of the App Pool account used for the Web App

    spence@harbar.net
    03 January 2013


#>
asnp Microsoft.SharePoint.PowerShell

## UPDATE THESE VARS ##
$waAppPoolUserName = "CORP\fimspcontent"
$waAppPoolName = "SharePoint Content"


$waUrl = "https://fimportal.corp.contoso.com"
$hostHeader = "fimportal.corp.contoso.com"
$webAppName = "FIM Portal"
$contentDBName = "FIMSP_Content_Portal"
$ownerEmail = "administrator@corp.contoso.com"
$ownerAlias = "CORP\administrator"

## END VARS ##


# Create Managed Account
Write-Host "Please supply the password for the $waAppPoolUserName Account..."
$appPoolCred = Get-Credential $waAppPoolUserName
Write-Host "Creating Managed Account..."
$waAppPoolAccount = New-SPManagedAccount -Credential $appPoolCred

# Create a new SSL Web App in the default Proxy Group using Windows Classic on Port 80 with host header
Write-Host "Creating Web Application..."
$webApp = New-SPWebApplication -ApplicationPool $waAppPoolName -ApplicationPoolAccount $waAppPoolAccount -Name $webAppName -Port 443 -SecureSocketsLayer:$true -AuthenticationMethod NTLM -HostHeader $hostHeader  -DatabaseName $contentDBName

# configure ViewState as FIM likes it
Write-Host "Configuring View State..."
$contentService = [Microsoft.SharePoint.Administration.SPWebService]::ContentService;
$contentService.ViewStateOnServer = $false;
$contentService.Update();

# Create a root Site Collection in 2010 mode
Write-Host "Creating root Site Collection..."
New-SPSite -Url $waUrl -owneralias $ownerAlias -ownerEmail $ownerEmail -Template "STS#1" -CompatibilityLevel 14

Write-Host "Disabling self service upgrade..."
$spSite = Get-SpSite($waUrl);
$spSite.AllowSelfServiceUpgrade = $false

Write-Host "FIM SP Web Application done!"

We need to apply a SSL certificate to the IIS web site for the FIM Portal as well, using the same approach as we did for Central Administration.

Let’s talk thru the various “interesting” aspects of this configuration.

First our Web Application is created using Classic Authentication mode. This is because the FIM Portal makes use of Basic Kerberos Delegation. Basic Kerberos Delegation does NOT work in Claims mode (in SharePoint 2010 or 2013) as there is no Windows Identity to delegate - a very major ball drop by the SharePoint team, but it how it is. So we must be in Classic mode. Classic mode is deprecated in SharePoint 2013 so it will be interesting to see what the FIM team do in the future if a future version of SharePoint actually removes this mode.

We deliberately do NOT configure Negotiate (Kerberos) authentication on this Web Application at this point, as we want to be able to validate everything is in working order before setting up Kerberos Delegation later on. SharePoint rather stupidly removes the Negotiate provider from IIS when creating Web Applications.

Next up, we disable Server side View State by grabbing the Content Service and configuring its view state property. It’s critical to call the Update method after making this change as there is no direct Windows PowerShell to configure the Content Service.

We then create a Site Collection in SharePoint 2010 compatibility mode. This basically means the sites will look and feel and operate like SharePoint 2010 sites. The FIM Portal is incompatible with the SharePoint 2013 native mode. Thus we further disable the ability of Site Collection administrators to upgrade the mode. This configuration will generate SharePoint Health Analyzer warnings, but this is hard requirement for FIM, so we have no choice.

We use the Blank Site Template for the root Site Collection, as we won’t be using it for anything, there is no point deploying the other assets found in the Team Site and other templates.

Once the script is finished we should validate that Central Administration, the Web Application and Site Collection are functioning as expected by viewing them in the browser.

If we are browsing these sites from one of the servers hosting them, we must remember to configure the Loopback Check. We are now ready to proceed with the installation of the FIM Service and Portal.

Installing FIM Service and Portal

We will first perform the following steps on the first server which will run the FIM Service and Portal, and then rinse and repeat for the other server(s). From the FIM installation media, load up the splash page and click Install Service and Portal, and click Run when IE Security prompts you.

On the Welcome to the Forefront Identity Manager Service and Portal Setup Wizard page, click Next.

On the End User License Agreement page, check the I accept the terms in the License Agreement check box, and click Next.

On the FIM Customer Experience Improvement Program page, choose if you wish to join the program, and click Next.

On the Custom Setup page, select the FIM Service and FIM Portal components ONLY, and click Next.

On the Configure the FIM database connection page, enter SQLFIM as the Database Server and FIMService as the Database Name. Click the Create a new database radio button, and click Next.

On the Configure mail server connection page, enter the FQDN of the Exchange Server, and click Next.

On the Configure server certificate page, click the Select a certificate located in the local certificates store radio button, and click Select Cert.

On the Select a Certificate dialog, click the fimservice.corp.contoso.com certificate, and click OK.

Back on the Configure server certificate, click Next.

On the Configure the FIM service account page, enter fimservice as the Service Account Name, the Service Account Password, CORP as the Service Account Domain and the email address for the account as the Service Email Account. Click Next.

If the Account Security Warning page is displayed, the User Rights Assignments for the FIM Service account are not correctly configured. Click Back. Ensure the User Rights Assignments as detailed in the table above are correct before proceeding.

On the Configure the Forefront Identity Manager Service and Portal synchronization server page, enter the host name of the machine running the FIM Sync service and the FIM Management Agent Account, and click Next. It is not necessary to have deployed the FIM Sync service at this point and these details can be changed later.

On the Configure connection to the FIM Service page, enter fimservice.corp.contoso.com as the FIM Service Server address, and click Next.

On the second Configure connection to the FIM Service page, enter https://fimportal.corp.contoso.com as the Sharepoint site collection URL, and click Next. (Notice that SharePoint is first spelt correctly with an uppercase ‘P’ and then incorrectly with a lowercase ‘p’ :) Marketing will be mad!)

On the Configure optional portal homepage configuration page, click Next.

On the Configure security changes configured by setup page, check the Open ports 5725 and 5726 in firewall check box and the Grant authenticated users access to the FIM Portal site check box, and click Next. We can lock down access to the FIM Portal at a later date.

On the Enter optional password portal configuration leave both check boxes unchecked, and click Next. We can configure the Password Registration and Reset web sites later if we wish.

On the Install Forefront Identity Manager Service and Portal page, click Install.

Wait whilst the FIM Service and Portal is installed, which will take about five minutes. When the Completed the Forefront Identity Manager Service and Portal Setup Wizard page appears, click Finish.

We can quickly validate the FIM Portal is operational by browsing to https://fimportal.corp.contoso.com/IdentityManagement/. Notice that the Search UI is displayed to the far right of the page, and ‘Welcome, Administrator’ is on the left.

If we want to prevent users accessing the root site collection and have them automatically taken to the FIM Portal, we can configure an IIS Redirect on the FIM Portal web site:

Now users can access the portal by navigating to https://fimportal.corp.contoso.com. We need to make this change on all machines running the FIM Portal.

Configure Kerberos Delegation

Now that our FIM Service and Portal are installed, we configure Kerberos Authentication and Kerberos Constrained Delegation (KCD) for the constituent components. Our requirements are effectively that the FIM Portal (SharePoint) should use Kerberos Authentication only, and that it can delegate to the FIM Service. Additionally the FIM Service should be able to delegate to itself.

First, we require two Service Principal Names (SPNs), the following script will create them:

setspn -S FIMService/fimservice.corp.contoso.com CORP\fimservice
setspn -S HTTP/fimportal.corp.contoso.com CORP\fimspcontent

Note that the SPN service identifier for the portal is HTTP and NOT HTTPS. Note also that the port number is NOT required. We only need to register the FQDNs here as we will never access either service using a NetBIOS name, nor are they listening on such a name.

Now we configure Kerberos Constrained Delegation (KCD) from the FIMSPContent and the FIMService accounts to the FIM Service SPN. The following Windows PowerShell accomplishes this:

Import-Module ActiveDirectory

$fimPortalAccount = "fimspcontent"
$fimServiceAccount = "fimservice"
$fimServiceSpn = "FIMService/fimservice.corp.contoso.com"

Get-ADUser $fimPortalAccount | Set-ADObject -Add @{"msDS-AllowedToDelegateTo"="$fimServiceSpn"}
Get-ADUser $fimServiceAccount | Set-ADObject -Add @{"msDS-AllowedToDelegateTo"="$fimServiceSpn"}  

It is worth validating this configuration in Active Directory Users and Computers.

Next we will change the FIM Portal Web Application to use Negotiate (although the SharePoint cmdlet calls this Kerberos):

$fimPortalUrl = "https://fimportal.corp.contoso.com"
Set-SPWebApplication -Identity $fimPortalUrl -AuthenticationMethod Kerberos -Zone Default

Next, we need to configure IIS to use the application pool identity for Kerberos. We do this by editing the ApplicationHost.config file in the C:\Windows\System32\inetsrv\config directory on each machine running the FIM Portal.

1. Open ApplicationHost.config in Notepad.
2. Choose Find from the Edit menu, and enter FIM Portal, and click Find Next twice.
3. The following configuration elements will be shown immediately after the second match for “FIM Portal”:
   
   

       <location path="FIM Portal">
           <system.webServer>
               <handlers accessPolicy="Read, Execute, Script" />
               <security>
                   <authentication>
                       <windowsAuthentication enabled="true" useKernelMode="false">
                           <providers>
                               <clear />
                               <add value="Negotiate" />
                               <add value="NTLM" />
                           </providers>
                       </windowsAuthentication>
                       <anonymousAuthentication enabled="false" />
                       <digestAuthentication enabled="false" />
                       <basicAuthentication enabled="false" />
                   </authentication>
               </security>

   
   
4. Update the windowsAuthentication element to specify useAppPoolCredentials=”true”:
   
   

       <location path="FIM Portal">
           <system.webServer>
               <handlers accessPolicy="Read, Execute, Script" />
               <security>
                   <authentication>
                       <windowsAuthentication enabled="true" useKernelMode="false" useAppPoolCredentials="true">
                           <providers>
                               <clear />
                               <add value="Negotiate" />
                               <add value="NTLM" />
                           </providers>
                       </windowsAuthentication>
                       <anonymousAuthentication enabled="false" />
                       <digestAuthentication enabled="false" />
                       <basicAuthentication enabled="false" />
                   </authentication>
               </security>

   
   
5. Save and close ApplicationHost.config.

Despite the FIM documentation, it is NOT necessary to change any other elements in this file. We can also perform this configuration using AppCmd:

cd c:\windows\system32\inetsrv 
copy .\config\applicationHost.config .\config\applicationHost.config.bak 
.\appcmd.exe set config "FIM Portal" /section:windowsauthentication /useKernelMode:false /useAppPoolCredentials

Next we configure the FIM Portal to use Kerberos only, by disabling NTLM in the web.config file for the FIM Portal web site.

1. Open C:\inetpub\wwwroot\wss\VirtualDirectories\fimportal.corp.contoso.com443\web.config in Notepad
2. Choose Find from the Edit menu, and enter <resourceManagementClient, and click Find Next.
3. Edit the resourceManagement element to specify requireKerberos=”true”:
   
   

   <resourceManagementClient requireKerberos="true" resourceManagementServiceBaseAddress="http://fimservice.corp.contoso.com:5725" timeoutInMilliseconds="60000" />
   

4. Save and close web.config

At this point, we can validate the Kerberos Authentication configuration by visiting the FIM Portal in the browser and using KLIST.exe to view our Service Ticket.

Notice that the ‘Welcome, Administrator’ and Search box display is now jacked up! Toggling the authentication settings above will correct it. The power of Kerberos huh! A resource somewhere isn’t being returned. Not that important though, so we will ignore that for now.

If we deploy the Password Reset components then additional delegation settings are required (from the application pool account hosting Password Reset to the FIM Service). These settings are not covered in this article.

Phew! That’s it! We could choose to now configure additional lock down (such as restricted access to the Portal). However for this article we are done, and our FIM Portal is ready for use in our IdM solutions.

Conclusion

Deployment of SharePoint 2013 for the purposes of supporting the FIM Portal component involves a few specific configuration elements, and "legacy” authentication settings. This article has shown how to configure the FIM Service and Portal components on Windows Server 2012 and SharePoint 2013 with security and high availability in mind. We have performed the following tasks:

• Configured core infrastructure (AD, DNS, Certificates)
• Installed SharePoint Foundation 2013
• Created a SharePoint 2013 Farm
• Created a SharePoint 2013 Web Application and Site Collection with the correct properties for the FIM Portal
• Installed and configuring the FIM Service and Portal components
• Configured Kerberos for the FIM Service and Portal

Watch this space for more SharePoint & FIM articles in the near future!

s.