How to setup a load balanced FIM Portal and service deployment

Whether in production behind a hardware load balancer or in a virtualised lab running on your laptop one thing that everyone designing and playing with FIM should be doing is utilising a virtual, or load balanced, hostname for the portal and service. That is, instead of accessing the FIM Service via http://idmserver02/identitymanagement (or http://idmserver02:5725/resourcemanagementservice) you should be hitting something more abstract, and pleasing on the eye (and easy on the tongue), e.g. http://idaweb:5725/resourcemanagement or http://idm/identitymanagement (these are examples).

To do this requires a minor amount of additional effort. But it’s worth it, as there’s no way you’re rolling into production and exposing the system to end users via the server’s hostname.

The purpose of this blarticle (I’m combing the nouns blog and article admirably here right?) is to define this configuration. I’m going to write two different blog posts. In this first article we’ll assume a relatively small or simple setup and follow Microsoft guidance and work on the basis that we’re implementing two or three stand-alone WSS instances –not a WSS farm. I’ll come back to a farm deployment in in the future (the second post I mentioned) as it becomes necessary if you scale out beyond three or four nodes (the average, collective opinion of myself and other colleagues and, indeed, Brad and David in their book).

We’ll break this post into two distinct sets of configuration: WSS and IIS, and AD (Kerberos).

Installing FIM is easy and thoroughly documented on TechNet. I’m not going to touch on that. All the work is in getting SharePoint up and running using Kerberos (the only way you should configure Windows authentication in my opinion). For me, the SharePoint and IIS tasks blur and all fall into one category. And it’s the area where mistakes are often made, especially if you’re not familiar with SharePoint and/or IIS. And let’s say it here too. Setting SharePoint up is also easy. You just have to get your prerequisite tasks done first. The prerequisites are the Kerberos configuration, another area where there’s often confusion and mistakes are made, so we’ll start there.

Note. I’m going to assume that you’ve installed SharePoint. Personally I install SharePoint using the basic installation option without first installing IIS as the WSS installer takes care of the IIS role services for you. So the only prerequisites are a domain joined workstation with .NET 3.5.1. Literally run the SharePoint installation as an administrator (preferably a domain user) of the server and when prompted at the end of the installation to run the initial configuration wizard do so. The Kerberos configuration that I describe next can happen while SharePoint is installing, before you install or after. The WSS/IIS configuration happens once SharePoint has successfully installed.

Active Directory Domain Services (AD DS)/ Kerberos configuration

There are two separate configuration tasks that must be performed: the creation, or registration, of service principal names; and the configuration of constrained delegation.

Service accounts

The SharePoint web application (SharePoint – 80 if the wizard created it) needs a service account. As does the FIM Service and Portal. Neither account requires any special permissions or group membership however the account used to run the FIM Service and Portal does need an e-mail address and, if you’re making use of the Exchange features (i.e. EWS polling for the purpose of the Outlook add-in), a mailbox (hosted on Exchange 2007 or 2010 mailbox server). Look to the TechNet documentation for a thorough description (link at the end of this post).

Service Principal Names

There are two sets of configuration required to make Kerberos work:

  1. Service Principal Names (SPN) must be registered. The SharePoint service account requires a HTTP SPN and the FIM Service account requires an FIMService SPN.
  2. Constrained delegation must be configured. The SharePoint service account must be configured to delegate credentials to the FIMService service and the FIM Service account must be configured to delegate credentials to the FIMService service.

SETSPN should be used to configure SPNs. To configure the SPN you must run the following commands.

SPN registration

The following command(s) will only work on an NT 6.x version of Windows (Vista, 7, 2008 or 2008 R2). If you’re running from 2003 you’ll need to use the -a switch instead. Note also that the -f switch is optional -it simply queries the forest. When used in conjunction with the -s switch, which checks for uniqueness before updating the target object, the uniqueness check is forest wide instead of localised to the domain of the target.

setspn -f -s HTTP/<unqualifiedPortalAndServiceVirtualName> <DOMAIN\SharePointServiceAccount> 
setspn -f -s HTTP/<qualifiedPortalAndServiceVirtualName> <DOMAIN\SharePointServiceAccount> 
setspn -f -s FIMService/<unqualifiedPortalAndServiceVirtualName> <DOMAIN\FIMServiceAccount> 
setspn -f -s FIMService/<qualifiedPortalAndServiceVirtualName> <DOMAIN\FIMServiceAccount> 

e.g.

setspn -f -s HTTP/idaweb CORP\svcfimwss 
setspn -f -s HTTP/idaweb.corp.adatum.com CORP\svcfimwss 
setspn -f -s FIMService/idaweb CORP\svcfimsvc 
setspn -f -s FIMService/idaweb.corp.adatum.com CORP\svcfimsvc 

Note. The SPN that is registered for the FIM Service (the FIMService SPN) must match the value of the externalHostName attribute (in the FIM Service configuration file; the value specified during installation, e.g. idweb, or ida.contoso.com). No other SPN is technically required. I add unqualified and qualified names because the ADUC UI caters for this and because in many cases it’s required. It is not required for the FIM Service SPN however as the configuration file drives what SPN is built. Only the value of the externalHostName attribute is ever used so anything else is superfluous.

Constrained delegation configuration

Technically unconstrained delegation works and is permitted but you should never recommend or enforce this on your customer. Always use constrained delegation and don’t permit protocol transition unless you absolutely have to (which you don’t in this case). We’ll use Active Directory Users & Computers (ADUC) for this task. You can do this programmatically but I haven’t written an example to share so I’ll keep it simple.

Configure the ability for WSS to delegate credentials to the FIM Service

The following steps describe how to setup this delegation.

  1. If not already, open ADUC (DSA.MSC). Click View and select Advanced Features.
  2. Locate the service account that will/does run the SharePoint web application and open the properties for the object.
  3. Click the Delegation tab. Click Trust this user for delegation to specified services only and select Use Kerberos only.
  4. Click Add… then Users or Computers…
  5. Enter the name of the account that the FIM Service & Portal will/does run under and click OK.
  6. Select FIMService from the available services (there shouldn’t be anything else unless you’re being a little bit mental) and click OK.
  7. Click OK.

That’s the WSS service account configuration complete. Next we need to configure the account that runs the FIM Service.

Configure the ability for FIM Portal to delegate credentials to the FIM Service

The following steps describe how to setup this delegation.

  1. If not already, open ADUC (DSA.MSC). Click View and select Advanced Features.
  2. Locate the service account that will/does run the FIM Service & Portal and open the properties for the object.
  3. Click the Delegation tab. Click Trust this user for delegation to specified services only and select Use Kerberos only.
  4. Click Add… then Users or Computers…
  5. Enter the name of the account that the FIM Service & Portal will/does run under and click OK.
  6. Select FIMService from the available services and click OK.
  7. Click OK.

That’s the Kerberos configuration complete. Next we’ll configure IIS and then WSS.

Internet Information Services (IIS) configuration

To successfully authenticate using Kerberos with a WSS standalone system using an alternative name the IIS applicationHost.config file must be modified to instruct IIS to use the credentials of the application pool to decrypt [Kerberos session] tickets instead of the identity of the system (IIS is running as the machine).

Update.  Previously I mentioned, in a footnote, that you don’t have to disable Kernel mode authentication.  This is still technically true; however there is a reason many SharePoint folk turn it off.  The SharePoint product group don’t support it being on.  Furthermore there is a very minor bug in Windows 7 and Windows Server R2 that result in unnecessary prompts for authentication after a reset.  In order to be in a supported and valid state Kernel Mode authentication should be turned off on the web application (web site) used by SharePoint (and FIM).

To do this, perform the following steps using an elevated command prompt (click Start, type “command”, right click “Command Prompt” and choose “Run as administrator”):

cd %systemroot%\system32\inetsrv 
copy config\applicationHost.config config\applicationHost.config.bak 
appcmd set config "SharePoint - 80" /section:windowsauthentication /useKernelMode:false /useAppPoolCredentials:true /commit:MACHINE/WEBROOT/APPHOST

In the previous version of this post I described the manual steps to configure the applicationHost.config XML directly. This is no longer necessary. The above commands take a copy of the file (a backup) and set the required properties on the “SharePoint – 80” web application –the default web application if you perform a basic installation. For completeness, the original instructions are as follows. I recommend the APPCMD syntax every time. It’s just easier, repeatable and less error-prone. Thanks to Brad Turner for hammering away at a command prompt for 19 minutes to get the syntax correct. J

Open the applicationHost.config file in an elevated NOTEPAD.EXE.

  1. Press Ctrl+Fand type, exactly:
    location path="SharePoint - 80
  2. Scroll down until you find
    <System.WebServer>

    CrLf

    <Security>

    CrLf

    <Authentication>
  3. Modify
    <windowsAuthentication enabled="true">

    to become:

    <windowsAuthentication enabled="true" useKernelMode="true" useAppPoolCredentials="true">
  4. Save the file and close NOTEPAD.

The IIS configuration is complete. WSS must be configured to run under a service account now.

Windows SharePoint Services (WSS) configuration

There’s some core configuration required in WSS and some nice-to-have, but not essential configuration. I say not essential in an [unreadable] sardonic tone. It is really essential, it’s just that FIM will work without it. Two changes are therefore required:

  1. Configure the web application to run under a service account instead of NT AUTHORITY\Network Service.
  2. Define alternate access mappings.

To configure the SharePoint web application to run under a service account using the SharePoint Central administration application, open the central administration application and perform the following steps.

  1. Navigate to Operations | Security Configuration | Service Accounts.
  2. For the web service, select the Windows SharePoint Services Web Application.
  3. For the application pool, select SharePoint – 80.
  4. Add a username and password and click OK.

To configure the alternate access mappings perform the following steps, again from the central administration tool.

  1. Navigate to Operations | Global Configuration | Alternate access mappings.
  2. Select SharePoint – 80 from the Alternate Access Mapping Collection drop-down in the top right of the page.
  3. Click Edit Public URLs and modify the default value to that of your intended virtual host name, e.g. http://idaweb. Click Save.
  4. Click Add Internal URL and then enter the FQDN for the virtual name. Leave the zone as Default. Click Save.
  5. Repeat step four for any other valid names and also add the actual hostname as an internal URL too.

This is the SharePoint configuration complete. Execute IISRESET from an administrative command prompt and the configuration is complete.

Note both of the above configurations can be configured via the command line or scripted using the STSADM command line tool.

Wrap up

This post focuses on the configuration of one or more standalone SharePoint servers that will host the FIM Service and Portal. It doesn’t discuss separating the FIM Portal and FIM Service as there is no need to do that –nobody does it and Microsoft don’t recommend doing it. The crux of this post is this: SPNs must be registered on the service account for the SharePoint web application and the FIM Service and Portal. Once the SPNs have been registered Kerberos constrained delegation must be configured to delegate credentials from the web application to the FIM Service and from the FIM Service to the FIM Service. Once the Kerberos configuration is complete, IIS should be setup to use the application pool credentials for the SharePoint web application (as opposed to turning off Kernel mode authentication) and SharePoint must be configured to use a service account for the web application as well as use the load balanced/virtual name(s).

For instructions on how to install the FIM Service refer to http://go.microsoft.com/fwlink/?LinkID=165845.

For a walk through of the instructions described in this post please see this follow-up post.

Originally posted June 6th 2011.  Updated 4th October 2011.  Updates: Added APPCMD syntax; removed comment re. not turning Kernel Mode AuthN off; added instruction to turn off Kernel Mode AuthN; tweaked some formatting; added URL to follow-up post; added note re. FIM Service SPN.

Advertisements

About Paul Williams

IT consultant working for Microsoft specialising in Identity Management and Directory Services.
This entry was posted in FIM, SharePoint and tagged , , , , , , , , , , , , , , , . Bookmark the permalink.

11 Responses to How to setup a load balanced FIM Portal and service deployment

  1. Pingback: Installing FIM Portal and Service with a load balanced name | Yet another identity management blog

  2. Jim Zhou says:

    Hi Paul,
    Do you have another guide for How to setup a load balanced FIM Portal and service deployment on WSS farm?

    thank you
    Jim

    • Hi Jim,

      I haven’t written one yet. I planned on doing it and shelved it for a while as I wasn’t sure if it was worth it. The process for Kerberos and also AAM is exactly the same. The real difference is in the WSS installation. Patching is more fun too, but that’s a separate post again. Seeing as you’ve asked for it I will blog it -the SharePoint stuff mainly, however it’s going to have to wait a couple of weeks because of my current workload I’m afraid.

      In the meantime I recommend having a stab at installing a WSS farm (not much different from a basic installation other than you have to provide a service account for the farm to run under which removes the step re. defining a service account later and you have to use SQL) and installing FIM. Couple of points on installing FIM into a farm:

      1. You only install the portal once. So assuming FIM is on the WSS farm nodes you install the FIM Service & Portal when you first install FIM, and on subsequent nodes you only select the FIM Service when installing. There’s no need to install the portal as it’s in the shared WSS config database.
      2. You should install all nodes before updating any installations if possible. That is, install each FIM Service as RTM then go and patch them once all existing nodes are installed.

  3. Jim Zhou says:

    That’s what exactly I want to know from you. I was afraid to install the secound FIM portal and it will overwrite the first one. That might cause some damages.

  4. AnuarFromKazakhstan says:

    Hello!

    setspn -f -s HTTP/
    setspn -f -s HTTP/
    setspn -f -s FIMService/
    setspn -f -s FIMService/

    and

    setspn -f -s HTTP/idaweb CORP\svcfimwss
    setspn -f -s HTTP/idaweb.corp.adatum.com CORP\svcfimsvc
    setspn -f -s FIMService/idaweb CORP\svcfimwss
    setspn -f -s FIMService/idaweb.corp.adatum.com CORP\svcfimsvc

    dosnt match each other, which is right?

    • Good catch. There’s a typo. The first two should be SVCFIMWSS and the latter two SVCFIMSVC. It should read:

      setspn -f -s HTTP/idaweb CORP\svcfimwss
      setspn -f -s HTTP/idaweb.corp.adatum.com CORP\svcfimwss
      setspn -f -s FIMService/idaweb CORP\svcfimsvc
      setspn -f -s FIMService/idaweb.corp.adatum.com CORP\svcfimsvc

      I will update the post tonight. Thanks for pointing this out.

  5. Pingback: FIM Service Principal Names and Kerberos Delegation | Yet another identity management blog

  6. Majd says:

    How about if we want to install FIM Service on two separate virtual machines ? how could i be able to load balance between the two?

    • The article discusses the Kerberos configuration. You build multiple servers, correctly configure the SPNs and hostnames, etc. as per the blog and then use your preferred NLB solution to actually do the load balancing. You’ll need source-IP affinity/stickiness.

      Does this make sense?

  7. anwarmahmood says:

    I am deploying FIM 2010 R2 SP1.
    The customer has specified a pair of identical hosts, both running the password reset and password registration portals. There is a Netscaler to provide load balancing.
    The first server went in fine and works.
    When setting up the second server, the following command fails;
    setspn -S http/passwordregistration.domain HOST02$
    Duplicate SPN found, aborting operation!
    This does of course make sense; evidently, I cannot use the same SPN on both hosts.
    For context (I think it will be significant!) I am using Windows Server 2012|IIS8.
    Should I…
    1) disable kernel mode authentication
    2) remove the SPNs from the computer accounts
    3) add the SPN to the identity running the app pools?
    I think I know how to do this 🙂
    Anwar

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s