Guest Author: Joan Resnick Ehrlich

Kerberos is a network authentication protocol developed by MIT and named after the three-headed dog in Greek mythology, Kerberos. The Latinized name is Cerberus. For an explanation of the protocol see TechNet: Kerberos Explained and Wikipedia. For those who are curious about the dog, see Wikipedia with pictures. Kerberos has been a standard in Windows operating systems since Windows 2000 and the default used in Active Directory environments. Prior Microsoft operating systems used Microsoft-proprietary protocols, LM (LAN Manager) and its successor NTLM (NT LAN Manager) followed by NTLMv2. For information on NTLMv2, hereafter referred to as NTLM, see MSDN: Microsoft NTLM.

Kerberos is more secure than NTLM, as are other protocols available for use in current versions of Windows. For a list see Windows Authentication in the Windows Server 2008/2008 R2 TechNet Library. As that documentation explains, NTLM is still supported, used for authentication in workgroups and standalone systems (non-domain environments), and generally used as a fallback if Kerberos cannot be negotiated. Kerberos-only authentication can be forced so that authentication will fail if Kerberos is not negotiated, though I gather from my reading this depends on the application and application version. Too – I learn something new every day – beginning with Windows 7 and Windows Server 2008 R2 you can restrict NTLM authentication usage (Introducing the Restriction of NTLM Authentication). Finally, Microsoft has continually enhanced Kerberos authentication in Windows.

SharePoint can be configured with NTLM or Kerberos authentication. NTLM works out-of-the-box but there are additional steps required to make Kerberos work. And there are zillions of folks (or so it seems) who have either blogged about how difficult it is to get Kerberos to work with MOSS or have blogged about how to do it because of the difficulty. I’ve read that Kerberos configuration in SharePoint 2010 has been made easier, but I have no experience with MOSS as a reference and have not had to configure Kerberos until now. In our production environment as in our test environment SQL Reporting Services will not be on the same machine as SharePoint.  Kerberos is needed because of the “double-hop” authentication scenario; one hop to the SharePoint server and a second hop to the SQL server. NTLM authentication will inherently fail. (A thank you to the SharePoint911 team for that information during an “Ask the Experts” web session I attended.)

Prepping for Kerberos authentication

An “Aha!” experience can come with simply reading about something. Or not. With Kerberos authentication I understood the concept right enough from the reading but the configuration know-how needed the doing. It was much easier than I expected once I clearly understood what was needed and what to do. To configure SharePoint 2010 with Kerberos authentication I followed the guidance provided by Configure Kerberos authentication (SharePoint Server 2010) in the SharePoint Server 2010 Beta Library on TechNet. Here are the steps I took on my reformatted home server after installing SQL Server but prior to installing SharePoint 2010. All service accounts previously created still existed in Active Directory and so I simply reused them.

1. Created an SQL Server login for the spsadmin domain account which will be used to install and configure SharePoint, and then added the login to the DBCreator and Security Administrator roles. This is a general SharePoint requirement.
2. Added the spsadmin and spsfarm domain accounts to the server’s Local Administrators group. At work, being that SharePoint and SQL Server are on two separate servers I would add the accounts to each server’s group. This step is not in the TechNet documentation but sidesteps any installation issues due to insufficient privileges on the servers. The accounts can be removed later.
3. Decided to run the My Sites and Intranet application pools each under a separate domain account rather than the spsfarm account, and created two users accounts in Active Directory, spsmysitepool and spsapppool, respectively. (The latter in hindsight should have been more appropriately named.)

4. Made a list of the Service Principal Names (SPNs) that will be needed, matched to the domain accounts on which the SPNs will be set. In our Beta scenario SPNs are needed for the SQL Server instance and the Central Admin, Intranet, and My Sites web applications. SPNs for both the FQDN and NetBIOS host names had to be constructed. [MSDN: Name Format for Unique SPNs explains how an SPN is constructed.] The corresponding matching accounts on which the SPNs will be set are sqlservice, spsfarm, spsapppool, and spsmysitepool, respectively.

   Real or virtual host names can be used to construct an SPN. The TechNet documentation addresses both. The Central Admin web application uses the actual server name; hence the server name is used to construct the SPNs. For the Intranet and My Sites web applications I will use host headers.  We need to use host headers because we will host the My Sites site collection in a separate web application than the Intranet site collections and we want SharePoint 2010 Search to crawl both web applications. The TechNet documentation explains that SharePoint 2010 Search can crawl web applications configured to use Kerberos authentication only if the web applications are hosted on IIS virtual servers that are bound to port 80 or port 443 (HTTP default ports). Using host headers allows us to use the same IP address and port for both web applications. This is the first time I will configure host headers.

5. Set the SPNs. The SPNs are set on the servicePrincipalName attribute of the domain accounts. [User accounts are a type of object in Active Directory. Examples of other types of objects are computers, printers, and groups. Objects have attributes. servicePrincipalName is one of the attributes of user and computer objects.] Setting an SPN can be done using a command line tool, setspn.exe, or the Active Directory MMC snap-in ADSI Edit. Using ADSI Edit incorrectly can hose Active Directory. I first used it out of necessity and by now am comfortable with it (not to mention extremely careful to cancel out when not making a change). I wanted a visual peek, so ADSI Edit is what I used. Here are screenshots of the SPNs being set on the different accounts:
• sqlservice account:
  [MSSQLSvc is the service name for the SQL default instance MSSQLSERVER. See SQL BOL: Registering a Service Principal Name for information on configuring SPNs for SQL Server 2008 and 2008 R2.]


• spsfarm account:
  [The TechNet documentation calls for SPNs constructed with the Central Admin port number. However, I later found that until I also added SPNs without the port number I could not access Central Admin from a computer other than the server hosting Central Admin. That tip came from a forum thread I did not keep a reference to, but thank you. The screenshot is post-addition.]
  
  

  The host name is the same as that used in the SPNs for sqlservice only because the SharePoint Central Admin and SQL servers are one and the same.

• spsapppool account:



• mysitepool account:


6. Tested and verified Kerberos authentication is being used when connecting to SQL Server from a SharePoint 2010 server. I first waited for the AD changes to replicate to my other domain controller. This step is not in the TechNet documentation but ensures that the domain controller authenticated against has the AD changes. Methods to test SQL connectivity include SQL Server Management Studio and the SQL client connectivity tool SQLCMD. As my home server is both SQL and SharePoint, testing posed a problem. I had the SQL Server DB Engine installed on my Windows 7 laptop so I used Management Studio on the laptop to connect to the server. I then checked the Security log on the server for a successful logon event and verified that Kerberos authentication was used. The TechNet documentation references Event ID 540; that Event ID is for Windows Server 2003. For Windows Server 2008 and 2008 R2 the Event ID is 4624. Here is the pertinent output from the event:





Randy Franklin Smith’s Ultimate Windows Security site has a Windows Security Event Log Online Encyclopedia that always comes in handy.  Here is the information for Event ID 4624. “NULL SID” in the Subject: Security ID field looks disconcerting but Microsoft provides this description in the event: “The subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.” The Ultimate Windows Security event description indicates that NULL is a common value and the field is “not usually useful information.” The information contained in the Logon Type, New Logon, and Detailed Authentication Information sections provided the critical information and confirmed that Kerberos authentication was being used.

Prepping for SharePoint 2010 Installation

I was now ready to install the SharePoint 2010 Prerequisites, so I logged onto the SharePoint server from this point on as spsadmin. I decided to first install the Reporting Services Add-in for SharePoint 2010, which is a separate download from Microsoft. The RS Add-in can be installed before or after SharePoint is installed. TechNet: Using Access Services with SQL Reporting Services: Installing SQL Server 2008 R2 Reporting Services Add-In (SharePoint Server 2010) states that installing the RS Add-in prior to installing SharePoint 2010 means less steps. The installation process was a handful of screens and decision-free. A successful installation reported Event ID  11707:

After installing the RS Add-in I ran the SharePoint 2010 Prerequisites setup, installed the WCF fix, and rebooted.  The SharePoint 2010 installation and configuration followed.

Installing SharePoint 2010 and Running the Products Configuration Wizard

Installation

Installation is run on all of the SharePoint 2010 servers that will be in the farm before the Products Configuration Wizard is run. The SharePoint 2010 files (binaries) are installed and a few choices made:

 “Server Farm” for Installation type: (Ignore that the Standalone option is highlighted.)

“Complete” for Server Type:

File Locations for the SharePoint 2010 files and Search index files: (Note the warning about the index files location.)

Products Configuration Wizard (PSConfig UI):

The Products Configuration Wizard executable is psconfigui.exe and often referred to as PSConfig UI. The PSConfig command line tool executable is psconfig.exe and commonly referred to as PSConfig. This article deals with the Wizard UI only.

PSConfig UI is run first on the SharePoint server that will host the Central Administration site and then on all other SharePoint servers. When PSConfig UI is first run the option to “Create a new server farm” is selected. Only one server in a farm hosts Central Admin but you can later change which server. PSConfig UI creates the SharePoint_AdminContent<GUID> database which stores Central Administration site content. [GUID = Globally Unique Identifier. Here’s an easy-read explanation of a GUID: http://betterexplained.com/articles/the-quick-guide-to-guids/] PSConfig UI also creates the SharePoint_Config database which stores all configurations for the farm. SharePoint Technical Product Manager Bill Baer provides a brief description of these and the other SharePoint 2010 databases in his Introduction to the Microsoft SharePoint SharePoint 2010 Database Layer blog post.

Running PSConfig UI on the SharePoint server that will host Central Admin:

I created a new server farm:

Provided the database server and left the default name for the SharePoint configuration database. Used the farm account as the account to be used to connect to the configuration database from this server:

Set a passphrase, which is later needed when adding servers to the farm:

Set a port number for the Central Administration web application. A random port number is presented but can be changed.  And – Alert! – selected Kerberos as the authentication method:

After which I received this warning, to which I clicked Yes:

Verified all settings chosen were correct:

The Wizard completed successfully:

I then clicked Finish and Central Administration launched successfully. The next step was to verify that Kerberos authentication was being used to log on to Central Admin. This needed to be done as spsadmin from another SharePoint server. Lacking another SharePoint server I again used my Windows 7 laptop, which is when I discovered I needed to add SPNs without port numbers to the spsfarm account servicePrincipalName attribute, as I had described earlier. Until I added those SPNs a logon prompt would appear and any credentials entered would fail.

Running PSConfig UI on all other SharePoint servers

At this point, had I additional SharePoint servers to configure I would have run PSConfig UI on these servers, selected “Connect to an existing server farm”, and entered the passphrase when requested. On the “Completing the SharePoint Products Configuration Wizard” screen I would have selected the Advanced Settings button and verified that “Do not use this machine to host the web site” was selected:

Reconfiguring SharePoint to work with Kerberos post-installation

SharePoint can be reconfigured with Kerberos authentication post-installation if NTLM was initially selected. We would have attempted this at work, except we decided to switch SQL to a different physical server with more RAM and so blew away the existing installation and started over with Kerberos.

Installing SharePoint on the SQL Server at work

We were required to install and configure SharePoint on the SQL server at work. This was necessary because the server with the instance of SQL Reporting Services in SharePoint integrated mode needs to be joined to the farm. This step is not necessary if the RS instance is installed on a SharePoint server. [Licensing costs dictated our setup.]

We did run into a bit of difficulty. We used SQL Server 2008 R2 BOL: How to install a SharePoint Web front-end on a Report Server. The documentation specifies (as of this writing) to select “Advanced” for Installation Type and “Web front-end” for Server Type during installation. As you can clearly see from the previous screenshots those options are not there. What to do?

One post to the Microsoft SharePoint 2010 – Setup, Upgrade, Administration and Operation later, we had our answer for the Beta thanks to SharePoint MVPs Paul Stork and Todd Klindt: Choose Server Farm, Complete. The only difference between Complete and WFE-only is the number of binaries copied to the server. If you do not start the services on that server in Central Admin SharePoint will then ignore those services. Todd Klindt said he read that a WFE-only role can be scripted from the command line and that one of the example config.xml files might be WFE-only. I went looking for the example config.xml file, had no clue what to look for, realized I probably should be looking in the installation executable, extracted that, and found some config.xml files in the “Files” folder subfolders related to installation type but no WFE-only. So we installed SharePoint on the SQL server using the same process as for installing and configuring SharePoint on additional servers, making sure to verify that the server was not selected to host Central Admin. We will wait for the RTM to see if the WFE-only option is eliminated or added back into the PSConfig UI or provided via scripting, and whether the documentation is updated accordingly and/or the community blogs about it. We left the SharePoint services running on the SQL server until we configure RS-SharePoint integration; perhaps then we can figure out which if any services can be stopped. I prefer only as much SharePoint on the SQL Server as is necessary for Reporting Services to work.

In Part 9 of this series I will enumerate the warnings and errors that appeared in the Event Logs post-installation and explain the steps I took to resolve them when possible. Part 10 will pick up with the next step in the TechNet documentation, Search configuration. Part 11 will walk through the final steps: creating the Intranet and My Site web applications and site collections.

Guest Author: Joan Resnick Ehrlich

Joan Resnick Ehrlich has been in the IT industry for 15 years and is Corporate IT Administrator for a mid-sized company on Long Island, NY. Prior to entering the industry Joan was a business researcher, and she enjoys combining her research skills with IT work. In addition to SharePoint, her primary responsibilities include Windows Server, Active Directory, Exchange Server, and SQL Server.