Pages

Monday, January 14, 2008

Kerberos Configuration [MOSS 2007]

Introduction

I know you want to stay away from Kerberos configuratio. But belive me once you are past Kerberos, it usualy gets much easier. Some of the integrations with MOSS such as SSRS and other native features such as RSS web part would work well when you have Kerberos configured.

While configuring Kerberos for MOSS, I have come across some interesting topics. I wanted to put all the bits and pices together and give one single chapter on Kerberos Configuration for MOSS. Ok, lets give it a try..

Introduction to Kerberos

What is Kerberos?

The name "Kerberos" is derived from Greek mythology. Cerberus is the Latin variant of Kerberos. Kerberos the three-headed watchdog that guards the entrance to the lower world or Hades. It is a child of the giant Typhon and Echidna, a monstrous creature herself, being half woman and half snake. Originally, the dog was portrayed having fifty or hundred heads but was later pictured with only three heads (and sometimes with the tail of a serpent). Cerberus permitted new spirits to enter the realm of dead, but allowed none of them to leave. Only a few ever managed to sneak past the creature, among which Orpheus, who lulled it to sleep by playing his lyre, and Heracles, who brought it to the land of the living for a while (being the last of his Twelve Labors.)

Like the mythical creature, the Kerberos security system guards electronic transmissions that are sent across the Internet.

Kerberos is a mature network authentication protocol designed to provide strong authentication for client/server applications by using shared secret-key cryptography.

Kerberos authentication is a form of Windows Authentication that allows delegation of credentials through multiple application layers and across multiple servers – unlike NTLM, which will pass user credentials through one layer only.

Implementing Kerberos

Kerberos authentication can either be implemented in a constrained delegation model (i.e trusting specific user/service accounts for delegation and using these accounts to run the applications) or in a full delegation model (i.e trusting machines for delegation and using the Local System or Network Service accounts to run the applications). It is however, the responsibility of each individual client to determine the best delegation model, whether it is constrained delegation or full delegation, that will satisfy the needs and constraints for their respective organizations.

What is “double-hop” issue?

Double-hop” is where a user authenticates to a web server and that web server then needs to impersonate the user against another service.

When this happens, the user’s authentication ticket is ‘hopping’ across two services; this is not allowed in NTLM and you will have to user Kerberos to do this.

Why implement Kerberos in MOSS?

Kerberos authentication is faster

Kerberos security resolves the 'double hop' authentication issue in MOSS when integrating with more than one application that requires the user impersonation.

Integrating or adding more services such as Excel Services, BDC, SQL Server 2005 Analysis Services/ Reporting Services and so on will require extra steps.

High level Steps for implementing Kerberos in MOSS

Preparation for setting up Kerberos.

Setting up SPN for the service accounts

Setting up SPN for the URLs

Configuring Service Accounts for Trust for Delegation

Enabling Kerberos for the MOSS Web Applications.

Configuring COM+ for web application pool account.

Testing the Kerberos Setup.

Detailed Steps for implementing Kerberos in MOSS

Preparation for setting up Kerberos

Make sure all the servers in the loop (MOSS, SQL and Domain Controllers) have the same time set

Inconsistent time settings are one of the primary causes of Kerberos related issues.

Keep the following handy.

All the service account names.

Access to AD with administrator login.

SetSPN utility from Windows Resource Kit.

Access to MOSS servers with login that has local administrator permission.

Names of MOSS related web applications and their application pools.

Client user with client computer to test post Kerberos setup.

Setting SPNs for Service Accounts

The first step in enabling Kerberos for SharePoint is to configure Service Principle Names (SPNs) for your SharePoint service accounts in Active Directory.

Consider ‘least privilege account principle'; this basically means that each distinct service inside the SharePoint farm will have its own domain user account

In summary, you should have the following accounts:

SQL Server Service Account: Account used by SQL to run all SQL services

Server Farm Account

SSP Service Account

Office SharePoint Server Search Account

Default Content Access Account

User Profile and Properties Content Access Account

Excel Services Unattended Account

One account per application pool: This is typically three accounts; SSPAdministration, MySite and your main 'Portal' or 'Intranet'.

SPNs are used by Kerberos to ensure that only certain accounts have permission to delegate a specific service on a user's behalf.

An SPN needs to be configured for each service and address that the account needs to delegate for. SPNs are configured by using SetSPN.exe (download here) which a command line is provided as part of the Windows 2003 resource kit.

This table outlines the commands that are required to create the right SPNs for each of the relevant SharePoint service accounts, however please bear the following points in mind:

Some services require the fully qualified domain name (FQDN) even if your users only use the host name. For example if user type http://portal to get to you main portal and you Active Directory is called Domain.local then the FQDN is Portal.Domain.Local

Some SPNs require the host name which is the FQDN without the .domain.local bit on the end. In the example above, this would simply be portal

For all user accounts you must include the domain prefix.

Below is an example for a single server farm in a domain called ‘domain.local’ where the MOSS server is called 'Server'.

The example assumes three host headers for web applications which are called 'My Site', 'Portal' and 'SSPAdmin'.

The 'least privilege account principle' has been used in this example and the accounts are fairly descriptively named.

How to configure a Windows SharePoint Services virtual server to use Kerberos authentication and how to switch from Kerberos authentication back to NTLM authentication: http://support.microsoft.com/?kbid=832769

How to use Kerberos authentication in SQL Server: http://support.microsoft.com/kb/319723/

4 comments:

Anonymous
said...

Hello Rajesh, I actually have an issue using Kerboeros authentication using MOSS: when I connect to the MOSS server from a computer not integrated in the domain, I cannot run reports in Reporting Services in integrated mode. I've been investigating using Kerberos tool, and authentication is forced in this case to NTLM. Seems to be because maxhine is not in domain.What do you think of this?Thanks for your help, Ben.

Hi,i wish to change my current production environment to kerberos. are you sure there is no problem with communication of the sharepoint 2007 servers with sql server 2008? just perform these steps for SQL related accounts too?