As a follow up to my previous post, How to setup a load balanced FIM Portal and service deployment, I wanted to walk through the configuration with an example. I’ll follow the steps of the previous post using the server names of a set of VMs.
My lab is made up of three Windows Server 2008 R2 Servers (Virtual Machines):
|Fully qualified domain name||Lab roles/functions|
|tsinfra.corp.tailspin-toys.com||AD DS Domain Controller (corp.tailspin-toys.com)|
|Exchange Server 2010 (basic setup, all common roles)|
|Enterprise Root CA (Certificate Services role, default setup)|
|tsdb01.corp.tailspin-toys.com||SQL Server 2008 R2 Enterprise|
|SQL Server 2008 R2 Cumulative Update #7|
|tsapp01.corp.tailspin-toys.com||Windows SharePoint Services 3.0 x64 with SP2|
|FIM Synchronization Service (build 4.0.2592.0 –RTM)|
|FIM Service & Portal (build 4.0.2592.0 –RTM)|
|FIM Synchronization Service (build 4.0.3576.2 –latest CU)|
|FIM Service & Portal (build 4.0.3576.2 –latest CU)|
FIM will be installed on TSAPP01 using the hostname IDWEB. Access will be via HTTPS, e.g. https://idweb/identitymanagement however under the covers the real portal name (from a Kerberos perspective) will be idweb.tailspin-toys.com. Note that I’ve dropped the CORP domain. I usually setup my lab environments with a child domain (from a DNS namespace perspective) and always utilise the “real” domain for intranet services. I like to think that adds a touch of realism to the environment.
The following service accounts have been created (I’m only focussing on the Service & Portal and WSS in this post, so I’ll omit everything not used in the installation).
|Display Name||Account Name|
|FIM Service & Portal Account||CORP\svcfimsys|
|FIM Synchronization Service Account||CORP\svcfimsync|
|WSS – IDWEB – Web Application Account||CORP\svcwssidweb|
Note. CORP\svcfimsys has an Exchange mailbox and an e-mail address of firstname.lastname@example.org.
Service Principal Names
We’ll register two SPNs for the FIM Service and two for SharePoint. We register the unqualified name and a fully qualified name. Note that the fully qualified name is not the true FQDN of the AD DS domain but rather is the DNS name, which omits the CORP domain.
From an elevated command prompt on any of the servers, the following commands are used.
setspn -s HTTP/idweb CORP\svcwssfimidweb
setspn -s HTTP/idweb CORP\svcwssfimidweb.tailspin-toys.com
setspn -s FIMService/idweb CORP\svcfimsys
setspn -s FIMService/idweb.tailspin-toys.com CORP\svcfimsys.tailspin-toys.com
The -S switch registers the SPN if there isn’t a duplicate in the domain. You can make the uniqueness verification forest wide by including the -F switch.
Verification is achieved using the -L switch. The following is the output from running setspn -l CORP\svcfimsys & setspn -l CORP\svcfimwsssvc.
C:\>setspn -l CORP\svcfimsys & setspn -l CORP\svcfimwsssvc
Registered ServicePrincipalNames for CN=FIM Service & Portal,OU=forefront-identi
Registered ServicePrincipalNames for CN=FIM WSS Portal Account,OU=forefront-iden
As stated earlier I’m not using the actual AD DS DNS name in either command. This is worth pointing out because the important part of Kerberos authentication is that the client “builds” the same SPN that is actually used by the server. With Internet explorer the SPN that it looks for is derived from the FQDN within the URL. What I do is implement a CNAME of IDWEB in the corp.tailspin-toys.com DNS domain. This CNAME points to idweb.tailspin-toys.com. Internet Explorer therefore constructs an SPN of HTTP/idweb.tailspin-toys.com.
Interestingly I utilise Alternate Access Mapping (AAM) within SharePoint so that the FQDN is hidden from the user, leaving a shorter and cleaner URL of https://idweb/identitymanagement.
Kerberos Constrained Delegation
Once the SPNs have been registered two delegations are required:
- The FIM Service & Portal account needs to be able to delegate credentials to itself. Or, specifically, the Portal needs to delegate credentials to the service.
- The SharePoint web application account needs to be able to delegate credentials to the FIM Service & Portal account.
The following figures illustrate the Delegation tab of both the SVCFIMWSSSVC and SVCFIMSYS service accounts. To expose the delegation tab you must have enabled “advanced view” (View | Advanced Features) in Active Directory Users & Computers (ADUC) and, the account in question must have an SPN.
Internet Information Services (IIS) configuration
The web site used by the default SharePoint web application must be configured to use the credentials of the application pool if we’re not turning off Kernel Mode authentication (a security feature that improves performance). On the SharePoint (FIM Service & Portal) server, tsapp01 in our case, we open an elevated NOTEPAD and then open the file %systemroot%\system32\inetsrv\config\applicationHost.config. We use “Find” (Ctrl + F) to locate location path=”SharePoint – 80. And then we modify <windowsAuthentication enabled=”true”> to become: <windowsAuthentication enabled=”true” useKernelMode=”true” useAppPoolCredentials=”true”>. Figure #3 shows a screenshot.
Underneath the <handlers> node is <security><authentication><windowsAuthentication>.
After making the described change save the file. Next we set the service account for the SharePoint web application.
Windows SharePoint Services (WSS) configuration
There are two configuration changes required within SharePoint Central Administration: the service account and the alternate access mappings.
To change the service account open central administration and navigate to Operations| Security Configuration | Service Accounts. Select Windows SharePoint Services Web Application as the web service and SharePoint – 80 as the application pool. Enter the username and password and click OK.
Click OK when prompted with this dialog.
At this point the configuration is done. After an IISRESET everything will work, however before we do that we’re going to configure the alternate access mappings.
Alternate Access Mappings
Within the central administration tool we navigate to Operations | Global Configuration | Alternate access mappings. In the top right we select SharePoint – 80 from the Alternate Access Mapping Collection. Next we click Edit Public URLs and change the default to http://idweb or https://idweb (depending on whether or not you want to use HTTPS, in my case I’m using HTTPS) and click Save.
Next we click Add Internal URL and then enter an URL that can be used to access the site. We repeat this process for each name. In our case we add the following additional names:
The following screenshot (figure #7) depicts my configuration which defines both HTTP and HTTPS.
At this point it’s time to bounce IIS. From an elevated command prompt type IISRESET.
After the IISRESET all that’s left to do is install FIM Service & Portal. When installing FIM the public facing name is IDWEB, usually entered in lowercase.
You then access FIM using either https://idweb/identitymanagement or https://idweb.tailspin-toys.com/identitymanagement.
If everything has been done correctly FIM will load as expected.
Going back to what I said in the beginning re. using non-standard names, because I use a CNAME that resolves to idweb.tailspin-toys.com and I configured FIM with the unqualified name of idweb I’ll get a Kerberos service ticket for HTTP/idweb.tailspin-toys.com and FIMService/idweb, as depicted below (figure #9).
The above screenshot is a non-elevated command prompt. I’ve simply executed KLIST without any arguments, which is the same as running KLIST TICKETS. I stress the fact that I’m using a non-elevated shell here. The set of tickets is different in your elevated shell as EXPLORER is not running under elevated credentials.
You might notice that I happily interchange between https://idweb and https://idweb.tailspin-toys.com. Work is needed to block HTTP or redirect HTTP to HTTPS and encourage one name over the other, however the other important aspect that I’d like to point out is that there is no certificate error using either the unqualified or qualified name. The reason for this is SAN: Subject Alternate Name. I build my certificate request with a common name of CN=idweb. What I use here is irrelevant really as Windows ignores the CN when a SAN is specified. For completeness I specify three DNS SANs: idweb, idweb.tailspin-toys.com and idweb.corp.tailspin-toys.com.
Here’s a couple of screenshots of my enrolment wizard.
I select Web Server and click More information is required to enrol for this certificate. Click here to configure settings.
I enter the CN of the unqualified hostname into the Subject name field. I also add the unqualified hostname, as well as the fully qualified hostname of the AD DNS domain and the DNS domain-name into the Alternative name field, using a Type of DNS. Remember SChannel.dll ignores the CN when there’s a SAN so you have to make sure all names are in the SAN even if you have the name as the CN.
I provide a Friendly name and Description (these are optional but helpful) and click OK. The remainder of the defaults are fine for my purpose.
I then click Enroll.
Then Finish and I’m done. Here’s the certificate.
Now I create a binding on the IIS web site to use this certificate.