FIM 2010 R2: Kerberos Authentication Setup

FIM 2010 R2: Kerberos Authentication Setup

One of the new features in FIM 2010 R2 (currently BETA) is the addition of the extranet scenario for the SSPR (Self Service Password Reset). This feature comes with additional IIS websites and thus authentication configuration to perform. The goal of this article is to explain which SPN’s (Service Principal Names) to register and what delegation to configure.


Introduction

In the article written for FIM 2010 we considered the following services:

  • Database for the FIM Service (SQL Service)
  • FIM Service
  • FIM Portal (Windows Sharepoint Services (WSS))

Now we are adding two new services:

  • Password Registration Site
  • Password Reset Site

Now bear in mind that that we are not focusing on the overall component design. The following information is correct whether all roles (services) are installed on the same box or separated in a multi-tier setup.

note Note
FIM 2010 only supported WSS for the FIM Portal. FIM 2010 R2 will also support SharePoint 2010 Foundation.

Services and SPN's

SQL Service

FIM Service

FIM Portal (on WSS/SharePoint 2010 Foundation)

Password Registration Site & Password Reset Site

For these sites we use a new service account, namely sa_fimpw. I choose to use it for both sites. For now I don’t see any real benefit in splitting this across two service accounts.

Kerberos Delegation Configuration

The following delegation configurations should be put in place:

  1. sa_fimpw trusted for delegation to FIMService/FIMSvc.contoso.com
  2. sa_wss trusted for delegation to FIMService/FIMSvc.contoso.com
  3. sa_fimsvc trusted for delegation to FIMService/FIMSvc.contoso.com

So in words: both the password site application pool identities and the FIM portal application pool identity have to be trusted for delegation to the FIMService SPN. And the FIM Service account should also trusted to the FIMService SPN.

Conclusion

Choosing dedicated URL’s to designate your services might seem overkill, or overly complex. But when combining more and more roles on the same server it's a necessity. By adding dedicated service accounts/application pool identities you are making the setup “understandable” and extremely flexible.

Using the name of your server to access all services on that box might seem a lot easier to setup, but in the end it's a lot more complex to configure, understand and support. Also from an end-user perspective it’s absurd. For instance do you want your users to use these URLs:

Don't you think they’ll be better off with this:

The FIM 2010 R2 Service & Portal installer perfectly supports this concept (which uses IIS Host Headers in the background to allow multiple sites to use port 80). So go forward!

note Important
Use A records in DNS as IE doesn’t play nice with CNAME records and Kerberos.

See also

 

note Note
To provide feedback about this article, create a post on the FIM TechNet Forum.
Sort by: Published Date | Most Recent | Most Useful
Comments
  • You might want to make a note that the R2 RC docs (incorrectly) show using the machine acocunt as delegating to FIM service for the Password reset IIS site. Your article here is correct in that regard.

  • I am confused in the part, as follows:

    "The following delegation configurations should be put in place:

    1.sa_fimpw trusted for delegation to FIMService/FIMSvc.contoso.com

    2.sa_wss trusted for delegation to FIMService/FIMSvc.contoso.com

    3.sa_fimsvc trusted for delegation to FIMService/FIMSvc.contoso.com

    So in words: both the password site application pool identities and the FIM portal application pool identy have to be trusted for delegation to the FIMService SPN. And the FIM Service account should also trusted to the FIMService SPN."

    In "have to be trusted for delegation to the FIMService SPN" I assume you are saying that FIMService stands for an SPN? Do you mean the spn for the Fim Service Service account or for the Fim Service server?

    And when you say trust for delegation to the FimService SPN, how do you trust delegation to an SPN?

    Please define more clearly exactly what FimService is, as a newbie, this is confusing.

    Partly because when I set this thing up my DB is named FIMService(though I know that is not what your refer but nonetheless confusing.)

    To further show my confusion, I didn't know SPN's could have names, ie: FIMService.

    I am trying to setup my configuration where we do not have to use the portals as apart of the url as in:

    https://pwreg.contoso.com

    and

    https://pwreset.contoso.com

    instead of

    https://pwreg.contoso.com:122

    and

    pwreset.contoso.com

    Forgive my ignorance but it really would help to clarify.

  • GPD, don't worry asking if something is unclear :) But perhaps you might be better of at the FIM TechNet Forums, these are more actively monitored by a wider public.

    Either way, some explanation:

    There's a Windows Service which is called the "Forefront Idenity Management Service". We often call it the "FIM Service". It typically uses a database called FIMService but that is up to the person installing it. In Kerberos authentication, each service being accessed is represent by a URL and a service type. The URL is required to so that you can actually "find" the service, and the service type is so you can specify what is actually available at the given URL. So for a website this service is called HTTP. As such an SPN is of the form HTTP/mysite.contoso.com. Do not confuse this with an URL you enter in IE. That is of the form HTTP://mysite.contoso.com.

    So in the FIM Service context the Microsoft developers who wrote FIM have chosen "FIMService" as type of for the SPN. Just like the SQL devs choose MSQLsvc as type for the SQL service.

    Is that a bit more clear?

  • Does anything have to be done differently for HTTPS? I can't imagine it's wise running these services over HTTP.

  • Nope, HTTPS just use the same servicetype (HTTP/) and does not need the port (443) to be mentioned in the SPN. So the above should apply without any modifications.

  • Understanding that Kerberos is more secure and efficient, but is it necessary to get FIM portals working?

Page 1 of 1 (6 items)