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.
In the article written for FIM 2010 we considered the following services:
Now we are adding two new services:
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.
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.
The following delegation configurations should be put in place:
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.
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 eassier 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!
Richard Mueller edited Revision 1. Comment: Fix <a name> tag in HTML so TOC works
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
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?