The goal of this article is to provide some background information regarding the Kerberos related configuration steps of the FIM Portal and FIM Service. The article has been written in such a way so that most of the points can in fact be used for any application
requiring Kerberos. This article will not discuss the various possible FIM Topologies. All information should be valid regardless whether all roles are combined on a single server or split across multiple servers.
Throughout the article a demo domain will be used. The domain which will be referenced as an example is contoso.com (NetBIOS name: CONTOSO).
↑ Back to top
Before we can start configuring SPN's (Service Principal Names) we have to determine what services we want to enable for Kerberos authentication. A typical FIM Portal deployment has the following services:
The following picture provides an overview of these services.
Kerberos is all about authenticating principals to a service. Each principal is represented by an account in AD. This can either be a computer or a user account. Before Kerberos can take place, each service should be represented by an account in AD. Again
this can either be a computer or a user account. Therefore it's important to determine which account represents a given service.
The list below provides an overview of our services and their associated identities.
Besides the principal representing a service, we also need to determine a name to access the service. Choosing names can be rather important when actual people are involved. Check the following examples:
In the picture above several client-server communication arrows have been pictured. In our example we will go with the following names to access the services:
Clients have to be able to resolve the names for these services. We can register these records in DNS. It might seem convenient to use an alias (CNAME) record for some of the services. However this is a bad idea as explained in the following paragraph. Using
a CNAME record would ensure that updating the server its IP has no influence on the service name record. However CNAME records resolve in another way than A records. A client requesting a Kerberos ticket for a given service will ask AD a ticket for whatever
the name resolves to.
This is how a client will resolve those names:
So we got a name and an identity for our service. How do we tell AD that these belong together? Ahah! Now we get to the Service Principal Names (SPN's). Whenever someone wants to use Kerberos to authenticate to a given service, they contact the Key Distribution
Centre (KDC) and ask for a service ticket. The KDC is running on each domain controller. It knows which ticket to hand out because the client specified the service it wants a ticket for. The service was in fact specified by its name. More particularly by using
the Service Principal Name (SPN).
An SPN is based upon the following format <service>/<fqdn>:<port>
In our example we will execute the following commands:
Setspn -S MSSQLsvc/fimsql.contoso.com:1433 sa_sqlsvc Setspn -S MSSQLsvc/fimsql:1433 sa_sqlsvc Setspn -S FIMService/fimsvc.contoso.com sa_fimsvc Setspn -S FIMService/fimsvc sa_fimsvc Setspn -S HTTP/fimportal.contoso.com sa_wss
Setspn -S HTTP/fimportal sa_wss
When the above steps have been implemented, both the FIM Service and SQL will start accepting Kerberos. However IIS is slightly different. In fact skipping this particular step will often break your configuration all together. One of the symptoms when having
a bad Kerberos implementation is the following: you type the URL of your website, you get presented with an authentication prompt, and no matter how many times you correctly enter your credentials, you keep getting prompted over and over again.
This issue occurs because by default IIS uses the account of the server to validate service tickets instead of the Application Pool identity. We can force IIS to use the identity of the application pool by configuring this in the applicationHost.config configuration
The following steps are required to configure Kerberos Authentication to work with a custom Application Pool Identity.
Launch an elevated command prompt and execute the following commands:
path="SharePoint - 80">
"SharePoint - 80"
The above might actually be different in your environment. You need to locate the path of the IIS site which represent your FIM Portal WSS site.
Add useAppPoolCredentials="true" so the line looks like: <windowsAuthentication
Save the file and exit notepad
Execute the following command: iisreset
Now that we got Kerberos authentication working for all of the involved services we have to determine whether additional configuration is required. Sometimes it's obvious that Kerberos delegation has to be configured, sometimes it's less obvious. Either
way, it's advised to check the product specific documentation to be sure. Kerberos delegation will allow a service to impersonate a visiting user and authenticate to another service as if it were the user himself who visits that service.
FIM Installation Guide we know that the following delegation scenarios are required:
To allow a given service to delegate to an other service, we have to configure delegation on the service its service account to the delegated service its SPN. Delegation can be configured using Active Directory Users & Computers (ADUC). As explained in the
previous section we have to configure the following delegation scenario's:
For the Portal to be able to delegate to the FIM Service we would have to:
And the resulting Delegation tab for the sa_wss account:
For the FIM Service to be able to delegate to the FIM Service we would have to:
The above procedure assumes your domain is in 2003 DFL or higher. Windows 2000 DFL only has unconstrained delegation available.
Optionally you can configure the FIM Portal to only accept Kerberos. This is explained in the FIM Installation Guide > Installing The FIM 2010 Server Components > Activating The Kerberos Protocol Only (link)
The following steps are required to force Kerberos Authentication for the FIM Portal.
Locate the element <resourceManagementClient
. . . />
. . . />
. . . />
Add requireKerberos="true" so that it reads <resourceManagementClient
. . . />
. . . />