SharePoint and Kerberos Incorrect SPN Error, The HTTP request is unauthorized with client authentication scheme 'Negotiate'

This post is related to an issue I have faced a couple of times in recent months, and I thought I would share my experience for anyone troubleshooting a similar issue.

My SharePoint web applications are set to use Negotiate (Kerberos), so I am assuming you have been through the process of setting up Kerberos authentication.

A great guide linked here by the way.

We have strict change control for production farms so I have only faced this in two staging farms where less stringent change management has meant configuration changes have been made and 'broken' Kerberos authentication.

But this could easily happen in a less tightly controlled production environment, which unfortunately I have too much experience with in the past!

The symptoms could be in many forms, depending how you are interacting with SharePoint.

I was trying to activate some features on a site and was receiving an error in PowerShell:

The HTTP request is unauthorized with client authentication scheme 'Negotiate'. The authentication header received from the server was 'Negotiate'

I then tried to browse the site in internet explorer and was prompted for my credentials, which would not be accepted.

There was no failing back to NTLM so I was stuck at this point.

To enable the Kerberos events in event viewer you will need to check you have the below registry entry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters

Registry Value: 

LogLevel

Value Type: 

REG_DWORD

Value Data: 

0x1

If the entry does not exist, create it.

Check the event viewer under system events you should begin to see Kerberos events when trying to authenticate to the problematic site.

Now I could see it was clearly a Kerberos authentication issue and checking the SPNs is the first logical step.

Check the application pool account running the web application, lets say as an example it is: domain\MattTestAccount

For Kerberos to work this account should have SPNs assigned to it.

in command prompt:

setspn -l domain\MattTestAccount

You should then see all SPNs for that service account listed.

If the SPN for your web application is not displayed you have found the issue, and this was the the problem in my case.

How could this have happened when it was previously working?

In my instance, at some point the application pool account running the IIS site had been changed, maybe to make the app pool accounts consistent, maybe to have individual accounts per web app, there are a multitude of reasons but the important thing is you have found the root cause of the issue.

Now you need to set assign the SPN to the correct service account and your Kerberos authentication issue will be resolved.

Guidance on setting SPNs and all other required configuration is in the guide linked at the start of this post.

Thanks for reading,

Matt

Surfacing SQL Cube Data Through Excel Pivot Table and SharePoint Excel Services

Having recently done some projects involving data connections to SQL Cube data, one of the many way we surfaced the data to end users was via an Excel pivot table and Excel Services on a SharePoint page.

I thought I would share the configuration steps, as this is a simple and effective way to enhance the SharePoint content and provide your SharePoint users with some useful BI data.

In this example we are going to use a set of stored credentials to access the SQL data source and need to set this up in the SharePoint Secure Store service application.

I will refer to the SQL cube just as a data source, because most of this post is applicable when accessing other data sources whatever they may be.

In Central Administration > Service applications

Select 'New' from the ribbon to create a new target application.

Name your target application ID, in this case we will be using a group mapping. See the explanation on the left of the fields for more detail.

We just need the username and password for the service account we will use to connect to the data source, so we can leave this section as default.

Set the administrator, and the members.

The members are users who will be allowed to use the stored credentials to connect to the data source.

Now the ID has been created we can set the credentials.

Insert the service account credentials, this is the account which now needs to be permissions on the data source.

Now we have created the secure store target application ID we can open Excel.

In the data tab, click on connections.

Add a new connection.

You will need to browse, and find your data source files.

On my machine I have a data sources folder in my documents which contains some template .odc files.

Use one of these files to fire the wizard.

In this instance I am using the connection shown above for an SSAS server, again this could be used for a different data source type.

Enter the SQL server and instance name for the cube and leave the log on credentials as is for now, we will change this in the next step.

You user doing this configuration will need access to the cube or this will fail when you hit next, as it needs to connect to the server.

It has found the server, and I can choose the database and cube that I want.

Name your file, this will be saved to your data sources folder, before finishing we can set the authentication settings.

Here we can set it to use the stored credentials that we set in SharePoint at the start.

Lets now insert a PivotTable to test the connection.

Choose connection.

Select the data connection we have created.

The Pivot table of our data should now be added.

This  sheet will now load the PivotTable in Excel services when added to a SharePoint page, bear in mind that users you want to be able to load the data source will need to be members of the Secure Store target application ID so you could use AD groups if this is a large number of users.

Thanks for reading,

Matt

Load Testing your SharePoint 2013 Servers - Visual Studio 2012 Load Test

So I have been using the Visual Studio load testing for every Infrastructure roll out I have worked on since it was released!

It's a great tool for testing all web servers not just SharePoint.

I am going to run through a very basic test, I found that there is plenty of useful information out there on this subject. But as I always do in my blogs I am trying to pull all the required information together in one easy to follow step by step guide.

I found other sources with steps for creating a web test, but no mention of a load test and similarly load test instructions with no mention of creating the web test first.

So the basic principals I use when planning a load test are:

You can create a web test in your Visual Studio project. This is just a recording of some steps you do in a browser, Visual Studio will then take that recording, remove the junk from the HTTP requests and leave just the calls to the web site you want to repeat over and over in your load test later on.

Once we have a web test, this could be of a single page load, multiple document uploads or anything you like. We then create a load test and configure that load test based on our requirements.

In that load test you can configure the number of concurrent users which is going to create the load on your servers!

Now for the steps.

Create a new Visual Studio project

 

 

Name your project.

Hit the record button to begin capturing your test in the browser which should open automatically.

Make sure that Internet explorer enhanced security is off (IE ESC) or this won't start and you will get an error. You can do this in server manager.

Browse to a site and begin performing the tasks you want your load test to simulate.

Hit stop recording once you have captured the simulated set of tasks. For my needs I just loaded three pages.

You will see once you stop that the web test is saved in your project, we can now use this is the base for our load test.

Right click the project title in solution explorer.

Add > Load Test

Follow the wizard to create the load test.

There is various configuration options in the wizard that you may wish to change dependent on your scenario and test requirements.

Name your Load test.

Set your number of concurrent users, you may find you need to tweak this and try some different numbers to see how the server reacts to the load.

My virtual server has 16GB RAM and 4 processors so lets see how it gets on with 100 concurrent page views.

Read through the descriptions of the different test mix models, I went for the number of virtual users to simulate 100 users.

Click add to choose our recorded web test.

Select the web test to add it to the load test. You could always have multiple web tests, for example one to simulate uploads and one for page views so that it all runs on the server concurrently.

You can tweak the distribution if you want, this ties in with the mix models if you want to set only a percentage of your users to be running the test at the same time.

You have the option to change network and browser types, not required in my basic example.

You can set computers and counter sets here too.

I'm just going to fire up resource monitor to show you how the server reacts.

Set the duration of the test.

Right click the load test and select 'Run Load Test'

Check the impact on your server!

If it's not enough just tweak the number of concurrent users, I find it useful to have a few load tests with different number of users so you can see how the servers react to 100, 200, 300 users and so on.

Thanks for reading,
Matt

Colour Coding SharePoint 2013 Central Admin Appearance Using Themes

A quick post I'd like to share as I am sure this can be useful for a lot of SharePoint admins.

As you are all probably aware you can change the theme of any SharePoint site from site settings.

Within Central Administration this option just leads to a blank theme gallery.

A problem I face regularly is having multiple server sessions open which include multiple farm central administration pages.

Sometimes I may have Production, Staging and Development Central Administration sessions open while testing and deploying through the environments.

By colour coding these environments it becomes quickly obvious which farm you are now in, and reduces your risk of making a mistake of which environment you are working in.

In my scenario I could also be working on different regional farms, so UK, USA and Asia all have a Production, Staging and Development.... you can forgive the confusion at busy times.

As I said a short and sweet tip that may be of interest to some administrators.

You can also label your Central Adminstration within the top banner and below is a great blog post covering that in detail.

http://www.wictorwilen.se/sharepoint-2013-central-administration-productivity-tip

Default colour scheme (Notice the 'Production' label at the top).

To access the themes simply take your Central Admin URL - http://server1:2013/default.aspx

and replace the /default.aspx with /_layouts/15/designgallery.aspx

 http://server1:2013/_layouts/15/designgallery.aspx

Choose a theme to suit this environment and save.

So now I have blue for Production and Orange for Staging, nice and easy to differentiate in a hurry.

Thanks for reading,

Matt

Checking your SSL Key file, CSR and Certificate Match

I have been doing a lot of work around security and in particular SSL with SharePoint this year (you might have noticed from my recent posts!).

This obviously leaves me spending a fair amount of time generating and installing certificates for the various farms and sites.

Recently upon receving my certificate from the certificate generation team I could not generate the required PFX file using OpenSSL.

After looking around in my various folders I noticed I had a lot of old CSR files and Key files knocking around and it becomes difficult to know which is the latest version! (I should be better at housekeeping I know!).

So a colleague passed on to me some useful information to check that your CSR/Key/Cert files match before trying to install them or generate PFX files as this will cause issues.

Using OpenSSL use the below commands to check the modulus of your files and ensure consistency between them.

To check the modulus of the certificate file:

x509 -noout -modulus -in certificatename.crt

To check the modulus of the Key file:

rsa -noout -modulus -in privatekeyname.key

To check the modulus of the CSR file:

req -noout -modulus -in csrname.csr

If you run these commands you will get the modulus printed out and be able to check them against each other to ensure they match and were not generated seperately with a different key etc..

I hope this helps out for those who are generating certificates regularly and have had problems with multiple versions of those certificates!

Matt

Changing SharePoint Host Named Site Collection Default URL

After changing a site from http to https I was unable to change the default zone URL for the SharePoint site which was hosting host named site collections.

Having the default zone as http was causing multiple issues (Workflows, OWA, Search) as lots of requests were still using http and our load balancer was forcing all traffic to https.

You have some PowerShell available to aid the administration of URLs for host named site collections.

Get-SPSiteURL
Set-SPSiteURL

Firstly I edited by default AAM in Central admin to be https://test.matt.com.

Now using PowerShell I'll show how my site looks currently.

Get-SPSiteURL -Identity http://test.matt.com

Using Set-SPSiteURL you can add new URLs to host named site collection for different zones.

Set-SPSiteUrl (Get-SPSite 'http://test.matt.com') -Url 'https://test.matt.com' -Zone Intranet

Get-SPSiteURL -Identity http://test.matt.com

You will see your additional URL in separate zone.

You can see I have set multiple zone URLs for the host named site collection.

You will not however be able to change the default zone URL with PowerShell SPSite command.

Set-SPSiteUrl (Get-SPSite 'http://test.matt.com') -Url 'https://test.matt.com' -Zone Default

I needed the default zone for the root site to change so that all my host named site collections within the web application would also inherit https by default.

So I removed the Intranet zone URL I added as I do not need this I need to change the default zone URL.

Remove-SPSiteURL -URL http://test.matt.com

Get-SPSiteUrl -Identity http://test.matt.com

Back to just a single URL.

So we have to go back in time and break out stsadm.exe

Open command prompt and run CD C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\BIN


Then run the following command:

stsadm -o renamesite -oldurl http://test.matt.com -newurl https://test.matt.com

And finally lets now check our default URL

Get-SPSiteUrl -Identity https://test.matt.com (Use your new URL here)

Its now changed the default URL!

Something to bare in mind is that this has changed the default URL for the host named site collection. The web application will still have the original default URL in the configuration database and you cannot change this without recreating the web application.

This was a pain for me so hope it can be of help!