RSS Viewer web part authentication requirements

In B2, configuring the RSS Viewer web part to display an RSS feed from a MOSS site nearly always worked without difficulty.  In B2TR, you may encounter a stubborn error “The RSS webpart does not support authenticated feeds” when trying to display an RSS feed from a MOSS site.  The authentication behavior has changed, to match the original design that was not implemented properly in B2.  RSS Viewer will now only work with Authenticated feeds (default for MOSS) when the MOSS server is setup with Kerberos authentication.  Technical details: In B2, the  machine account was used to access the feed; since this account is part of “All Authenticated Users” most feeds just worked.  However, use of the machine account was considered to pose a security vulnerability.  In B2TR, this was fixed to connect to feeds as anonymous, then delegation support was explicitly added by having ASP.Net negotiate the authentication mechanism.

Changing to Kerberos authentication

1.       On the Central Administration page, click Application Management.

2.       Under the Application Security section, click Authentication Providers.

3.       Click the Default provider, and change Integrated Widows authentication to Negotiate (Kerberos)

 If SharePoint and the databases it uses are hosted on the same server, this is the only change required to enable RSS Viewer functionality to RSS feeds hosted by SharePoint.

If the SharePoint databases are hosted by a different server than is hosting SharePoint, further configuration is required to enable Kerberos delegation.  This is the recommended scenario for farm deployments.  To enable Kerberos delegation for a SharePoint web application, the account used for its application pool identity must be configured as “trusted for delegation” and have an SPN registered (see below).  If using Network Services for the AppPool identity, then this applies to the machine account.  Otherwise, it applies to the domain account configured for the AppPool identity.  The machine account of the database server must also have an SPN registered, although it is not necessary for it to be trusted for delegation.  The end-user accounts require neither an SPN nor “trusted for delegation.”

In an AD environment whose Domain Functional Level is set to Windows Server 2003, this level of trust can be focused using Constrained Delegation.   This ensures that the delegation trust is only permitted between the SharePoint WFE servers and the correct database server.

SPN

The MSDN article Security Briefs: Credentials and Delegation discusses several topics regarding SPNs and Kerberos delegation that are appropriate for this scenario, including use of the SETSPN and KERBTRAY tools, the "trusted for delegation" attribute, and how to configure Kerberos constrained delegation.