Implementing Kerberos for SharePoint running on Windows Server 2008 and IIS7

Before I start writing how to set up Kerberos authentication in SharePoint, let me explain our set up a little bit, i.e. server names, account names and so on that will be used in this guide:

WSSSERVER1 – SharePoint web front server

WSSSERVER2 – another web front server (optional)

DBSERVER1 – database server running Microsoft SQL Server 2005 SP2

Domain\wss_srvc_account – User account used to run SharePoint services

Domain\sql_srvc_account – User account used to run SQL services on database server

Domain\wss_apppool – User account used to run SharePoint web application pool

Domain\mysite_apppool – User account used to run My Site web application pool

Domain\sspadmin_apppool – User account used to run Shared Services Provider web application pool


To set up a Kerberos authentication in SharePoint (WSS or MOSS) you need to do a bunch of small configuration changes:

  1. Make sure that you have host headers set up for your SharePoint sites. For example, in case of Windows SharePoint Services you will have only the main SharePoint website, whereas in case of Microsoft Office SharePoint Server 2007 you will have main SharePoint website, My Site website, and Shared Services Provider Sites. For the sake of simplicity, let's call those host headers: http://sharepoint, http://mysite, http://sspadmin respectively.
  2. Update Alternate Access Mappings to point websites to website host headers. In other words, replace http://servername:2222 entry with http://sharepoint


  3. Add SPN records for:
    1. Hostnames and FQDN of computer account(s) of your SharePoint server(s), for example
      Setspn.exe -A HTTP/WSSSERVER1 DOMAIN\wss_ srvc_account
      Setspn.exe -A HTTP/WSSSERVER1.domain.local DOMAIN\wss_srvc_account
      Setspn.exe -A HTTP/WSSSERVER2 DOMAIN\wss_ srvc_account
      Setspn.exe -A HTTP/WSSSERVER2.domain.local DOMAIN\wss_srvc_account
    2. Hostnames and FQDN of computer account of your SQL server, for example
      Setspn.exe -A MSSQLSvc /DBSERVER1:1433 DOMAIN\sql_srvc_account
      Setspn.exe -A MSSQLSvc /DBSERVER1.domain.local:1433 DOMAIN\ sql_srvc_account
    3. Host headers for your SharePoint websites, for example
      Setspn.exe -A HTTP/INTRANET DOMAIN\wss_apppool
      Setspn.exe -A HTTP/ INTRANET. domain.local DOMAIN\wss_apppool
      Setspn.exe -A HTTP/MYSITE DOMAIN\mysite_apppool
      (Do not apply in case of WSS)
      Setspn.exe -A HTTP/MYSITE. domain.local DOMAIN\mysite_apppool
      (Do not apply in case of WSS)
      Setspn.exe -A HTTP/SSPADMIN DOMAIN\sspadmin_apppool
      (Do not apply in case of WSS)
      Setspn.exe -A HTTP/SSPADMIN. domain.local DOMAIN\sspadmin_apppool
      (Do not apply in case of WSS)


    1. Configure "Trust for Delegation" on all computer accounts and user accounts used in SharePoint configuration. To configure "Trust for delegation":
      1. Open Active Directory Users and Computers management console
      2. Right click on a user or computer account that require ""Trust for Delegation" configured and click on Properties
      3. Where you find this option in the GUI depends on the Active Directory functional level. In case of Windows 2000 domain, the option is under Account tab for user accounts and General tab for computer accounts. In case of Windows 2003 domain, the option is under a separate Delegation tab. Note: Delegation tab is only visible for accounts that have SPNs registered


  4. Configure Component Services to allow Local Launch and Activation permissions for IIS WAMREG Admin Service for all application pool accounts used in SharePoint configuration. To configure Component Services setting go Control Panel >> Component Services >> Computers >> My Computer >> DCOM Config >> properties of the "IIS WAMReg Admin Service" >> Security tab >> edit "Launch and Activate Permissions" >> add "Local Launch" and "Local Activation" permissions for all the application pool accounts


  5. Because in IIS7 HTTP.sys is handling the authentication, it is by default done under the LocalSystem account regardless of the application pool account you're using. However, because even a single SharePoint server configuration is now considered a web farm, we should use a domain account to run SharePoint application pools. As a result we need to modify applicationhost.config file to configure the useAppPoolCredentials attribute in system.webServer/security/authentication/Windows-Authentication configuration section to true.

    <windowsAuthentication enabled="true" useKernelMode="true" useAppPoolCredentials="true"/>



  6. Once you have made a change to applicationhost.config file you might start getting errors 6398, 7076, 6482 in your Event Viewer. To get rid of those errors you need to apply hotfix KB946517. This hotfix is currently is available for Windows Server 2003, XP and Vista and it is under development for Windows Server 2008. I have used Vista version of the hotfix on Windows Server 2008 and it seems to have worked fine (knocking on wood...)


  7. Now you're ready to switch your SharePoint web applications to Kerberos authentication. Open SharePoint Central Administration >> Application Management >> Authentication Providers >> choose your web application >> change authentication to Negotiate (Kerberos)



  8. In case of MOSS, to change your Shared Services Provider web application to use Kerberos authentication run the command: stsadm.exe -o SetSharedWebServiceAuthn –negotiate. Stsadm.exe is usually placed under C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\bin.



That's it, you should now have your web applications using more secure Kerberos authentication. You can use Fiddler ( to verify that your web application is in fact using Kerberos authentication. Here are a few links that will help you might find useful:

Related resources:

How to get Exchange 2007 running on a virtual server

It's been a while since I blogged about something. Maybe it's because I've been busy lately, maybe it's because of I've spent a week at the TechEd conference (the best conference ever, by the way) and a week working on my tan at Daytona Beach, or maybe it's because I'm just getting old and lazy. But I digress...

I have recently had the "pleasure" of installing Microsoft Exchange 2007 SP1 on a virtual server running Windows Server 2008. I was eager to try Microsoft's latest and greatest product. Originally I wanted to install it on Microsoft Virtual Server, but unfortunately MS Virtual Server doesn't support 64-bit virtual servers on a 32-bit host server! So, to get virtual server running, I had to rebuild the physical server, which makes no sense to me whatsoever. Since I was willing to do that, I had no choice but to go with VMWare Virtual Server which fully supports 64-bit virtual servers on a 32-bit host server. VMWare's product turned out to be an excellent product with tons of easy to use features. Hopefully, Microsoft's product will soon catch up.

Usually, I would never recommend running Exchange 2007 virtually in the production environment, unless you have a kick-a$$ host server to run it or if you have fewer than 50 mailboxes. But if you have to - or want to - run Exchange 2007 on VMWare Virtual Server, you need to know that Microsoft does not support this scenario. Even though for the most part it runs fine, there is a problem with the way VMWare virtual adapters work with IP6, which causes the problem with Outlook Anywhere connectivity.

Fortunately, there is a great article on Microsoft Exchange Team blog that helps you to deal with that problem: . Essentially, you need to turn off IP6 on your Exchange server NIC configuration and in the hosts.conf file. You also need to make sure that your Exchange server can talk to Global Catalogue servers by configuring RPCProxy port in the registry.

There is also a great online tool from Microsoft that helps you troubleshoot any connectivity issues with Exchange 2007/2003:

In conclusion, kudos to VMWare for the great product, and kudos to Microsoft for their detailed documentation to get things working, as well as providing great online tools for troubleshooting.

Getting Bluetooth working on Windows Server 2008

If your bluetooth adapter is a Broadcom Bluetooth 2.0 EDR, like the "ThinkPad Bluetooth with Enhanced Data Rate" or any Broadcom Bluetooth 2.0 EDR type adapter, you can follow the steps below to get bluetooth working on Windows Server 2008.

Required for install:

Vista or WS2008 x86:
Vista or WS2008 x64:

Hex Editor, e.g. WinHex or CodePad

1. If you down it, you will install this software. When Toshiba Setup say Plug your BT device, you'll click to cancel. Install is succesfull.

2. Open Device Manager (Start | Control Panel | Device Manager) or Start | Run... | devmgmt.msc

You find in Other devices - Bluetooth dongle. Get Properties of it. On fold Details you see Property, It scroll to Hardware Ids. In Value Box u see two line, e.g.:



You copy second line with short Ids ('USB\VID_0A5C&PID_2101')

3. Now you going to folder:
Vista or WS2008 x86: %PROGRAMFILES%\Toshiba\Bluetooth Toshiba Stack\Drivers\tosrfusb

Vista or WS2008 x64: %PROGRAMFILES(x86)%\Toshiba\Bluetooth Toshiba Stack\Drivers\tosrfusb

Here are files:, tosrfusb.inf, tosrfusb.sys
You need edited *.cat, and *.inf file.

4. Open tosrfusb.inf in Notepad.exe (e.g. Start | Run... | Notepad.exe)

Here you must edited line 161:

%TosrfUsb.DeviceDesc97%=TosrfUsb_Device,  USB\VID_0C24&PID_000F

and line 288:

%TosrfUsb.DeviceDesc97%=TosrfUsb_Device,  USB\VID_0C24&PID_000F

You edit this lines to:

%TosrfUsb.DeviceDesc97%=TosrfUsb_Device,  USB\VID_0A5C&PID_2101

And save as tosrfusb.inf (replace original file).

5. Open in Hex Editor (e.g. WinHex, CodePad).

Ctrl+F.. You need line of characters (but not find this data as text value!):





HWID97   ,usb\vid_0c24&pid_0005

There you must change value help by ASCI table, e.g.:





HWID97   ,usb\vid_0A5C&pid_2101

And save as (replace original file).

6. Now you can install your BT.

Vista or WS2008 x86: %PROGRAMFILES%\Toshiba\Bluetooth Toshiba Stack\ECCenter.exe

Vista or WS2008 x64: %PROGRAMFILES(x86)%\Toshiba\Bluetooth Toshiba Stack\ECCenter.exe

You must Ignore install not sign drivers and all is Okay.

[Source: MSDN Forums]

Windows Media Player Plugin for Firefox on Windows Server 2008

If anyone tried to install WMP plugin for Firefox on Windows Server 2008 (or any server os), they will get an error stating that server os are not supported. In order to get it working, you need to do the following steps.

  1. Rename wmpfirefoxplugin.exe to
  2. Extract it into a directory.
  3. Type the following command in a console:
    msiexec /a ffplugin.msi
  4. It will install it probably in C:\
  5. Copy this file, np-mswmp.dll, into your plugins directory of Firefox (usually C:\Program Files\Mozilla Firefox\plugins)
Restart Firefox and it should work.

How open source has influenced Windows Server 2008

I have found a very interesting article on Technet on how open source community has influenced Windows Server 2008. I think it is very encouraging that Microsoft is taking user’s feedback seriously and trying to integrating the improvements developed by open source community into its system. And, if they make a few bucks along the way by doing this, so be it.

One has to admit, there's no better enterprise level system then Windows server. Not yet, anyway. It's streamlined and well designed; it's an excellent tool for desktop and user support/control (OUs and policies). Exchange, ISA, WSUS, and many others integrate naturally into AD. It is about what public knows the best, at work, at home, and in the library. As much as I love Linux, it's not even close to being there. It's all dispersed, scattered-around collection of technology DIY's, that works, but has no core. For those who want to learn more about Windows Server 2008 and, as I am, are too lazy to read a book, here are some clear installation instructions from TrainSignal:

It will be interesting to see a similar lists for other Microsoft products, such as Office, SQL Server or Visual Studio.

Installing SQL Server 2005 on Windows Vista or Windows 2008: IIS 7.0 problem

Recently I tried to install SQL Server 2005 on Windows Vista and I have received a warning message for IIS Feature requirement on the System Configuration Check page of the SQL Server 2005 Setup program. This means that you won’t be able to install SQL Server components, requiring IIS, such as Reporting Services. The problems occurs because IIS 7.0 is much more customizable and has much more components, so some of the components required for RS installation are missing from the default IIS 7.0 install. Here is the list of the IIS components required for Reporting Services:



Static Content

Common HTTP Features

Default Document

Common HTTP Features

HTTP Redirection

Common HTTP Features

Directory Browsing

Common HTTP Features


Application Development

ISAPI Extension

Application Development

ISAPI Filters

Application Development

Windows Authentication


IIS Metabase

Management Tools


Management Tools


For instructions on how to install missing IIS components in Windows Vista, go to: (

For instructions on how to install missing IIS components in a Server Core installation of Windows Server 2008, go to:

The solution is also explained in Microsoft KB920201.