FIM Service Principal Names and Kerberos Delegation

Kerberos authentication and delegation.  A surprisingly complex subject for many.  But it shouldn’t be!

If truth be told I’ve been a little shocked at how difficult some folk involved in FIM projects (or general infrastructure projects) find implementing multiple-tier applications with Kerberos authentication.  Almost every FIM engagement requires explaining and re-explaining what service principal name (SPN) records are required, what DNS records are required and what delegates to what.  Don’t get me wrong –some multiple tier applications with multiple types of delegation to other potentially multiple tier applications gets complex, but not FIM.  FIM is easy.  It’s just that the TechNet documentation has, until very recently, done a reasonably poor job of explaining it.  Smile

Hopefully this short and succinct post will explain it for you.

I’m going to have to use example naming.  As with my other posts I’ll use the AD DS domain of and the DNS domain for enterprise applications of  We’ll agree that corporate security dictates unqualified hostnames are not allowed and we will be using SSL (HTTPS) –not that that matters in the slightest.

First things first.  The FIM Service and Portal

There are two accounts of interest here.  The account that runs the SharePoint application pool; and the account that runs the FIM Service.  Each account requires one SPN and there is one delegation required for portal access to work.

  1. The WSS/SharePoint account requires an SPN for the HTTP service class: HTTP/<fully-qualified-virtual-hostname>.  For example, in the example the two FIM Service and Portal nodes ( and are configured with SharePoint running as the account CORP\svcfimsp and the URL  In this instance the only SPN needed on the account CORP\svcfimsp is HTTP/
  2. The FIM Service account requires an SPN for the FIMService service class: FIMService<fully-qualified-virtual-hostname>.  For example, the account CORP\svcfimservice needs FIMService/

And that’s it.  The only remaining configuration is to configure Kerberos Constrained Delegation (KCD).  The SharePoint account delegates credentials, using the Kerberos protocol only, to the FIM Service application, i.e. CORP\svcfimsp –> FIMService/ (registered on CORP\svcfimservice).

So how do we configure that?  Like this:

Configure SPNs using SETSPN:

setspn -s HTTP/ CORP\svcspfim
setspn -s FIMService/ CORP\svcfimservice

Configure KCD using PowerShell:

# import the ad module
if(@(Get-Module -Name ActiveDirectory).Count -eq 0)
    Import-Module -Name ActiveDirectory;

# configurable variables
[String]$svcaccount = "svcfimsp";
[String]$fimsvcspn = "FIMService/";

# get the sharepoint svc account
$user = Get-ADObject -LDAPFilter "(&(objectCategory=person)(sAMAccountName=$svcaccount))";

# qualified delegation only (as per the examples)
Set-ADObject $user.DistinguishedName -Add @{ 
    "msDS-AllowedToDelegateTo" = $fimsvcspn;

# qualified and unqualified delegation (when you're using the AD DS namespace)
#Set-ADObject $user.DistinguishedName -Add @{ 
#    "msDS-AllowedToDelegateTo" = "FIMService/idweb", 
#    "FIMService/"

Note that only the following line is of any real interest (the rest is loading the AD PS module, getting the service account user object and some helpful comments).

Set-ADObject $user.DistinguishedName -Add @{ 
    "msDS-AllowedToDelegateTo" = $fimsvcspn;

Next.  The R2 SSPR portals

Each of these portals runs under a service account.  However only one of these accounts requires an SPN for the HTTP service class (and then only if intranet users are hitting it).  The registration application requires you authenticate in order to render it therefore an SPN is required for this web application.  The password reset portal is accessed anonymously –you can’t remember your password remember.  Lets assume we have the URLs: and  The respective service accounts (web application/application pool identity) accounts are CORP\svcfimpwdreg and CORP\svcfimpwdset.  The SPN for the registration portal is therefore:

  • HTTP/ registered on CORP\svcfimpwdreg;

Delegation?  No, none.  Contrary to popular belief these applications do not delegate credentials to the FIM Service.  The SID of each account is added to the FIM Service database during installation and all actions are carried out by the portal accounts (the trusted subsystem model) –and those accounts have specific, minimal access within the FIM Service.

OK, let’s configure the registration portal too.  Like this:

setspn -s HTTP/ CORP\svcfimpwdreg

Done.  That’s it.  You don’t need anything else.  SQL is out of scope.  As is SCSM and SSRS (for the Reporting).

And just in case you’re wondering, yes, all of my examples have used the same hostname for portal and service.  And no, that is not strictly required.  I just happily deployed with a portal of and a FIM Service address of  Following the above examples the only change is the FIMService SPN (and an additional DNS A resource record).  That’s instead.  And this all works nicely with unqualified hostnames too.  Just tweak the SPNs accordingly.


If you’re not using a virtual namespace and instead are using the same namespace as your AD DS domain, e.g. (portal) and (service) then it is best to register both the unqualified and qualified hostnames, e.g. HTTP/idweb and HTTP/; and FIMService/idweb and FIMService/

In the PowerShell example above I used Active Directory Web Services (AD WS).  For those of you who don’t have AD WS…

The PowerShell above requires AD WS which means you need a Windows Server 2008 R2 or later domain controller or the Active Directory Management Gateway Service (AD WS for Windows Server 2008 or Windows Server 2003).  If you don’t have that in place you need some other type of script or tool.  Here’s a simple script that has almost no requirements (on a supported OS).

# configurable variables
[String]$svcaccount = "svcspfim";
[String]$fimsvcspn = "FIMService/";

# get the SP svc accounts
[System.DirectoryServices.DirectorySearcher]$dss = New-Object System.DirectoryServices.DirectorySearcher("LDAP://DC=corp,DC=contoso,DC=com");
$dss.Filter = "(&(objectCategory=user)(sAMAccountName=$svcaccount))";
$dss.SearchScope = [System.DirectoryServices.SearchScope]::Subtree;
[String]$targetDN = ($dss.FindOne()).Path;

# add the kcd
[System.DirectoryServices.DirectoryEntry]$dst = New-Object System.DirectoryServices.DirectoryEntry($targetDN);

Hopefully that helps.  The first part of this post is relevant to both FIM and FIM R2.  The second part is obviously only relevant to FIM R2 as the SSPR portals are new in R2.

If you want some more prescriptive guidance please take a look at some older posts that describe how to configure FIM with a virtual name (the way you would in production):


About Paul Williams

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

Leave a Reply

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

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

Google photo

You are commenting using your Google 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 )

Connecting to %s