FIM 2010 R2: Kerberos Authentication Setup

Article
1/17/2024

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

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:

sa_fimpw trusted for delegation to FIMService/FIMSvc.contoso.com
sa_wss trusted for delegation to FIMService/FIMSvc.contoso.com
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!