betterITsolutions

In this part I will talk about configuring your SSP to use Kerberos.

The next step (if required in your environment) is to configure Kerberos for the Shared Services Provider. This includes root and virtual directory level Shared Services. A prerequisite for this step is the SharePoint Infrastructure Update (which was released post SP1).

Configuring the SSP Web Application is very similar to a normal Web Application, so we'll keep it brief. Assume we have the SSP's Web Application running on port 1234 not using a host header. Then, the commands to map the SPNs are as follows:


setspn –A HTTP/servername:1234 yourdomain\UserRunningAppPool
setspn –A HTTP/servername.yourdomain.com:1234 yourdomain\UserRunningAppPool


Turn on Kerberos authentication for the SSP Web Application as described for the content Web Application (previous post) and perform the same test, ensuring you see a successful Kerberos logon event in the Security log on the server hosting the SSP.

In order to fully configure Kerberos for the SSP and Excel Calculation Services, further SPNs must be set using a new, custom format. There are also STSADM commands to run and a change to be made to the registry of each server.

Map the SPNs with the following commands:


setspn –A MSSP/servername:56737/SSPName yourdomain\SSPServiceAccount
setspn –A MSSP/servername:56738/SSPName yourdomain\SSPServiceAccount


SSPName is simply the name you gave your SSP. It cannot contain extended characters so be sure to name your SSP with care at install time! You must also generate a pair of SPNs for each server in your farm. I.e. in a standard medium server farm (2 WFEs and 1 App server), you will set 6 SPNs, 2 for each server name.

Now run the necessary STSADM commands on a server in the farm:


stsadm –o setsharedwebserviceauthn –negotiate
stsadm –o set-ecssecurity –accessmodel delegation –ssp
stsadm –o execadmsvcjobs


In order, this sets the Shared Services Web Service to use Kerberos, Excel Calculation Services to use delegation and then forces the timer jobs to run immediately.

Lastly, each SharePoint Server will need a registry key adding to allow it to use the new custom format SPNs.

1. Run regedit
2. Go to the registry path HKLM\Software\Microsoft\Office Server\12.0 and right click 12.0 >> New >> DWORD Value
3. For Name type in KerberosSpnFormat and change the value from 0 (default) to 1.

After this step, you must reboot your server.

There is some additional configuration required within Component Services. In order to prevent the occurrence of DCOM errors, all of your Application Pool service accounts should have Local Launch and Local Activation permissions on the IIS WAMREG Admin Service object, most easily achieved by giving the permissions to the local groups: WSS_WPG and WSS_ADMIN_WPG (this ensures that newly created Application Pool service accounts are granted the permissions, since SharePoint adds them to this group). This is well documented elsewhere.

However, there's also a modification to be made to the servers in the farm within Component Services. Click on Start > Administrative Tools > Component Services. Expand Component Services > Computers, right click on My Computer and select Properties. On the Default Properties tab, change the Default Impersonation Level to Delegate and click on OK.

My Computer Properties

References

There are a huge number of references for configuring Kerberos. Here is a useful selection:

• Configure Kerberos Authentication (Office SharePoint Server)
• How to configure SQL Server 2008 Analysis Services and SQL Server 2005 Analysis Services to use Kerberos Authentication
• Kerberos Authentication & Excel Services
• The Moron's Guide to Kerberos, Version 2.0
• Essential Tips on Kerberos for SharePoint Deployers
• Service Principal Names (Windows) on MSDN
• The .NET Developer's Guide to Windows Security (in particular, Part 5: Network Security)

That concludes my guide to Kerberos for SharePoint. I hope you have found it useful and if you have any queries, please send them to me.

No Comments »

This part of the four part series will look at configuring Kerberos on SharePoint Web Applications.

The first thing we need to do is to map some SPNs (again) and the SPNs themselves depend on whether you are using CNAMEs or A Records to resolve your web sites. If you are using CNAMEs, whose targets are servers with associated A Records, you construct the SPN using the CNAME's target (i.e. the hostname in the A Record). In the case of an A Record, it's much simpler; just use the hostname in the A Record. If you're unsure and don't have access to DNS (for whatever reason) then ping the DNS name and see if it resolves directly to an IP address or tells you it's pinging another address. The former result indicates an A Record is in use, the latter indicates a CNAME.

In the case of CNAMEs, it'll often be the case that the target is a machine which will mean constructing SPNs based on that computer's name. There's a further complication in that the same SPN cannot be assigned to more than one account so if you have a collection of CNAMEs for different Web Applications all resolving to the same A Record, each Web Application must use the same domain account for its Application Pool Identity to maintain a unique mapping of SPNs (this will become clear below).

As an example, I am creating SPNs for a site served on the host header kerbtest on port 80 with an appropriate A Record associated with it. The fully qualified SPN is optional (depending on whether the site is ever accessed using the FQDN), but I would always include it.


setspn –A HTTP/kerbtest yourdomain\UserRunningAppPool
setspn –A HTTP/kerbtest.yourdomain.com yourdomain\UserRunningAppPool


Note that HTTP in this case refers to the HTTP service, NOT the protocol. A common mistake is to mistype the above and start them with HTTP://, which is incorrect.

If your domain functional level is Windows Server 2003 or later, you will need to make some changes on the Delegation tab of the user account running the Application Pool. In Active Directory Users and Computers, locate the user object, right click on it and select Properties. Click on the Delegation tab and change the setting to either Trust this user for delegation to any service (Kerberos only) or Trust this user for delegation to specified services only.

Delegation Tab

Some guides will discuss enabling delegation for the computer account in Active Directory as well, but this is only necessary if the service process is running under the Local System account, which is not the case here.

If constrained delegation (the more secure and, therefore, recommended option) is required, I would suggest making sure everything works with unconstrained delegation first, before pressing on with constrained.

Kerberos can be enabled either at Web Application creation time, or later. I would usually implement it later, and make sure that the Web Application functions correctly with NTLM first.

To change the Authentication Provider to Kerberos, from SharePoint Central Administration (SCA), click on Application Management. Click on Authentication providers under Application Security. Make sure that the correct Web Application is selected and then click on the Zone that you wish to move to Kerberos. I will click on Default. The only change you should need to make is to alter the IIS Authentication Settings by changing the radio button from NTLM to Negotiate (Kerberos). Click OK when the warning dialogue box appears and then scroll to the bottom of the page and click on Save.

Edit Authentication

From another machine on the domain (not one of the SharePoint web front end servers), browse to the Web Application. On the Web Server that you hit you should see an event with ID of 540 in the Security log, containing the following kind of information:


Event Type: Success Audit
Event Source: Security
Event Category: Logon/Logoff
Event ID: 540
Date: 09/07/2009
Time: 14:10:52
User: domain\user
Computer:
Description:
Successful Network Logon:
User Name:
Domain:
Logon ID: (0x0,0x2D996B)
Logon Type: 3
Logon Process: Kerberos
Authentication Package: Kerberos
Workstation Name:
Logon GUID: {5dea6995-63c8-8ab0-0b1d-e80325461c16}
Caller User Name: -
Caller Domain: -
Caller Logon ID: -
Caller Process ID: -
Transited Services: -
Source Network Address: 10.11.12.2
Source Port: 1301


Again, computer, domain and user names have been deliberately removed.

This concludes configuration of Kerberos for a SharePoint Content Web Application. In the final part I will describe how to switch the Shared Services Provider to Kerberos and also add a list of useful references for further reading.

No Comments »

I've had a few encounters with Kerberos so, as a result, I decided to collect what I have learnt together in a series of blog posts. Primarily my concern is with regards to enabling Kerberos Authentication for SharePoint, but I will add some general information, too.

Enabling Kerberos offers a few advantages over NTLM, it:

• Is less susceptible to replay attacks because it includes a timestamp of when the network traffic was sent
• Allows verification of servers through the use of Service Principal Names (SPNs)
• Reduces authentication traffic because authentication is valid until the tickets expire (or are manually purged)
• Allows authentication over multiple hops (via the use of delegation).

The last point is frequently the driving force in enabling Kerberos for SharePoint, although reduced authentication traffic and increased performance are also often cited. An example of where we might need authentication over multiple hops would be where we need to authenticate with a SharePoint Web Application, our credentials have to be passed on to a web service and this web service has to pass our credentials to SQL to retrieve data from a database. This is only possible if Kerberos is enabled and the intermediate accounts are trusted for delegation in Active Directory.

Concepts

There are some concepts key to Kerberos which are worth understanding. This is a very basic level understanding of them but hopefully will provide some insight.

What is a Service Principal Name?

An SPN is a string constructed using an arbitrary text name for a service, the computer name that the service is running on and the port. This then appears in the following format:

ServiceName/Computer:Port

An example would be MSSQLSvc/sqlserver01:1433

It is used to allow a client to uniquely identify an instance of a service.

To enable Kerberos we need to configure a mapping in Active Directory between SPNs and the account that the service is supposed to be running under. To do that, we either use ADSIEDIT or SETSPN (found in the Windows Server Support Tools or downloadable from Microsoft). You must at least be a domain administrator to perform these updates.

SETSPN

SETSPN is a command–line tool and has 3 switches that we're interested in:

–A to add an arbitrary SPN
–D to delete an arbitrary SPN
–L to list registered SPNs

The syntax we'll use is as follows:

setspn –A service/computer:port domain\user
setspn –D service/computer:port domain\user
setspn –L domain\user

Computer may be the NetBIOS name, Fully Qualified Domain Name (FQDN) or another DNS name – more about this later.

How Kerberos Works (very briefly)

Kerberos is an authentication service developed at MIT. The idea behind Kerberos is that both the user and service have a shared key and this is used to encrypt and decrypt something freshly created (for example a timestamp). If the wrong key is used at either end, decryption is not possible and authentication fails. In practise, what occurs is much more complicated, but this is the very basic idea.

When using Kerberos in a Microsoft environment, broadly speaking, the following occurs. A Kerberos authentication server will grant a ticket in a response to a client computer authentication request, as long as the request contains valid user credentials and a valid SPN (see above). This ticket can be used to access network resources. For the lifetime of the ticket (by default, it is 600 minutes, i.e. 10 hours) a new ticket does not have to be issued and this is how authentication traffic is reduced. For Kerberos to work, both the client and server must have a trusted connection to the domain Key Distribution Centre (KDC). The KDC distributes the shared secret keys to allow encryption to take place. Both computers also need to be able to access Active Directory directory services and the forest root domain is the centre of Kerberos authentication referrals.

In the next part I'll move on to talking about configuring Kerberos.

No Comments »