SharePoint 2013 Kerberos and Host Named Site Collections

In a previous post, “SharePoint 2013 Host Named Site Collections over SSL”, I outlined the procedures of setting up HNSC’s with SSL, but also mentioned the fact that in the absence of a wildcard SSL certificate you’ll need to add SAN’s to the certificate each time you provision an additional HNSC.  To me this is a major design consideration for a SharePoint farm as adding new HNSC’s results in a revoking/reissuing the certificate as new HNSC’s are added to the farm.

In this article I’ll cover the procedures to use Kerberos authentication on a web application that contains HNSC’s and interestingly enough we run into a similar issue as with the SSL certificates in that for each HNSC we need to create a SPN before Kerberos authentication will be used for that particular site collection.

This post does assume the following:

  • The Web Application that hosts HNSC’s has already been created and uses Claims/Kerberos as it’s authentication mechanism. 
  • The example is based on a SharePoint 2013 farm hosted on Windows 2008 R2 servers with the domain functional level at “Windows Server 2008 R2”.  That’s not to say this wouldn’t work on a SharePoint 2010 farm or in an Windows Server 2012 environment, but the examples will reflect SharePoint 2013 and Windows 2008 R2.

High level steps are listed below and performed in this order to illustrate when NTLM authentication is being used instead of Kerberos:

  • Configure DNS A Records
  • Create HNSC
  • Create HTTP SPN’s
  • Configure Delegation
  • Validate Kerberos Authentication

Configure DNS A Records

In order for Kerberos authentication to work properly a DNS A Record for the HNSC in question will need to be created and a CNAME alias will not work.  Whenever I create DNS entries for SharePoint I always create DNS A records even if Kerberos isn’t a requirement initially.  That way I’m covered if it becomes a requirement in the future.

  • Open DNS Manager (dnsmgmt.msc)
  • Expand the “Forward Lookup Zones”
  • Select the target domain (2008r2.local in our example)

HNSC-Kerb-01

  • Right click on the target domain and select “New Host (A or AAAA)…”

HNSC-Kerb-02

  • Complete the “Name” and “IP Address” fields and click “Add Host” to create the new entry.  The first field will be the name of the new HNSC being created while the second is the IP address to the web application or VIP if you are using load balancing.

HNSC-Kerb-03

  • Click “Done”
  • Review the verification dialogue and click “OK”
  • The record will now show up in the DNS Manager

HNSC-Kerb-04

  • Additional verification can be accomplished by pinging the new entry:

HNSC-Kerb-05

Create HNSC

In this step we create a HNSC called “Accounting” and illustrate that the authentication method used for the site is NTLM, even though Kerberos has been previously setup on the web application.

  • Launch the “SharePoint 2013 Management Shell” from one of the servers in the farm
  • Execute the following command in PowerShell to create the “Accounting” site that uses the DNS A-record of “acct.2008r2.local”.

image

Check SPN’s for the Web Application Service Account
  • Open a command prompt and issue the following command to check for SPN’s applied to the service account that the web application runs under.  Notice in this example an HTTP SPN has been created for the web application (hnsc.2008r2.local)

HNSC-Kerb-06

Check Authentication Type for the Web Application
  • Go to Central Administration
  • Under the “Web Applications” section click on the “Manage web applications” link

image

  • Highlight the web application that was configured to contain HNSC’s and click the “Authentication Providers” button in the ribbon.

HNSC-Kerb-09

  • In the “Authentication Providers” dialogue select the “Default” Zone link

HNSC-Kerb-10

  • In this example it Kerberos has been configured as the authentication mechanism

HNSC-Kerb-11

Validate Current Authentication Method for the “Accounting” site:

This step will illustrate the new HNSC collection “Accounting” is using the NTLM authentication method even though the web application hosting the site is configured to user Kerberos.

  • Navigate to the web site and check the security logs on the server to see what authentication type was used.

HNSC-Kerb-07

  • On the WFE where the request was processed open the Windows Security Log in Event Viewer.
  • Look for 4624 Event ID’s that came from the user account used to access the site.  The entry will demonstrate that NTLM was used to authenticate the user to the site.

HNSC-Kerb-08

Demonstrate that Kerberos is working for previously configured sites

In my lab environment I had previously configured a couple of HNSC’s to use Kerberos authentication by specifically adding a SPN for that site.  This step will demonstrate that Kerberos does indeed work on this web application when a separate SPN is created for the HNSC.  We will cover the procedures to create the SPN in a later step.

  • Open a command prompt and issue the following command to check for SPN’s applied to the service account that the web application runs under.  Notice that an HTTP entry was created for teams.2008r2.local.

HNSC-Kerb-06

  • From a web browser, we’ll navigate to https://teams.2008r2.local which in turn should generate a log entry on the WFE illustrating that Kerberos was used to authenticate the user.

HNSC-Kerb-12

  • On the WFE look at the security logs in the event viewer for an Event ID: 4624 for the authentication attempt that just occurred for the https://teams.2008r2.local site.
  • There should be an entry that identifies Kerberos was used to authenticate to the site.

HNSC-Kerb-13

Use KLIST to Display Kerberos Tickets on the Client Machine

An alternative to checking the server logs for the authentication type being used is to use the “klist.exe” utility on the client machine.  This will list the Kerberos Tickets that have been issued to the user.

  • From the client machine where SharePoint “Teams” site was accessed open a command prompt.
  • Type klist and hit enter to display the results.  Notice an entry exists for HTTP/teams.2008r2.local and the site was rendered using Kerberos authentication.  In order for the https://acct.2008r2.local site that was previously created to leverage Kerberos, we’ll need to create a HTTP SPN for that site.

HNSC-Kerb-14

Create HTTP SPN’s

In this step we’ll create two SPN’s for the HNSC “Accounting” that was previously created.  One thing to note is that even though we are using HTTPS to access the “Accounting” site, the SPN is created with HTTP as the type.  After performing this step the site will then leverage Kerberos instead of NTLM for the authentication method.

  • In a previous step we listed the SPN’s for the web applications service account and will issue that command again prior to creating the new HTTP SPN for the “Accounting” site.
  • Open a command prompt and type “setspn –L <domain>\<web app service account>.  Notice we do not have any entries for HTTP/acct or HTTP/acct.2008r2.local.

HNSC-Kerb-06

  • To create the necessary entries you’ll need to be a member of either the Domain Admins, Enterprise Admins,  or have been delegated the authority directly to your account.
  • Issue the following commands in the following format setspn –S HTTP/<domain name> <service account>:
    • setspn –S HTTP/acct 2008r2\SP_WebApps
    • setspn –S HTTP/acct.2008r2.loca 2008r2\SP_WebApps

HNSC-Kerb-15

  • Now that the SPN’s have been created issue the command to list them for the service account and verify the two entries exist.

HNSC-Kerb-16

Configure Delegation

Now that the SPN’s have been created for the “Accounting” HNSC we can optionally setup delegation on the service account for the web application.  It’s important to note that setting up delegation is only necessary if you are planning to setup access to external data sources such as a SQL server instance that resides outside the farm.  There are a couple of different options in setting up delegation, but we’ll just cover one of them in this example.

  • Open Active Directory Users and Computers
  • Locate the Service Account for the web application
  • Right click and select the properties
  • Select the “Delegation” tab
  • Select the “Trust this user for delegation to specified services only” radio button
  • Select the “Use Kerberos only” option
  • Click “Add”

HNSC-Kerb-17

  • Click on “Users or Computers…”
  • Add the service account for the web application
  • A lists of SPNs assigned to the service account will be listed.  Highlight the SPN’s that you want to use to delegate to other services and click “OK”

HNSC-Kerb-18

  • Click on the “Expanded” check box
  • The two entries should now be displayed on the Delegation tab of the account properties

HNSC-Kerb-19

Validate Kerberos Authentication

Now that the SPN has been created for the “Accounting” HNSC you can test the authentication against the site and verify whether or not it’s using Kerberos.

HNSC-Kerb-12

  • On the WFE look at the security logs in the event viewer for an Event ID: 4624 for the authentication attempt that just occurred for the https://teams.2008r2.local site.
  • There should be an entry that identifies Kerberos was used to authenticate to the site.

HNSC-Kerb-20

Use KLIST to Display Kerberos Tokens on the Client Machine

Now if we run the “klist” utility we’ll see the ticket entry for “HTTP/acct.2008r2.local”.

  • From the client machine used to access the SharePoint sites open a command prompt.
  • Type klist and hit enter to display the results.  Notice an entry exists for HTTP/acct.2008r2.local and the site was rendered using Kerberos authentication. 

HNSC-Kerb-21

Advertisements
Tagged with: , ,
Posted in HNSC, SharePoint 2013
One comment on “SharePoint 2013 Kerberos and Host Named Site Collections
  1. Markus says:

    Hi,
    for me it worked with a CNAME alias like that:

    1.) A Record = HNSC WebApp = hnsc01.contoso.com
    2.) registered HTTP/hnsc01.contoso.com Domain\SP_WebApp
    3.) create CNAME Alias and HNSC Site: teamsite.contoso.com

    i opened teamsite.contoso.com with IE11 or Word2010 afterwards with klist i see the ticket entry for hnsc01.contoso.com.

    The same happens with NTLM and saved credentials in the Windows Vault: The Entry is stored under hnsc01.contoso.com but authentication works without password prompt for CNAME Alias sites as well.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: