Configuring Kerberos authentication: Core configuration (SharePoint Server 2010)

 

Applies to: SharePoint Server 2010

In the first scenario you will configure two SharePoint Server 2010 web applications to use the Kerberos protocol for authenticating incoming client requests. For demonstration purposes, one web application will be configured to use standard ports (80/443) and the other will use a non-default port (5555). This scenario will be the basis of all the following scenarios which assume the activities below have been completed.

Important

It is a requirement to configure your web applications with classic Windows authentication using Kerberos authentication to ensure that the scenarios work as expected. Windows-Claims authentication can be used in some scenarios but may not produce the results detailed in the scenarios below.

In this scenario you do the following things:

  • Configure two web applications with default zones that use the Kerberos protocol for authentication

  • Create two test site collections, one in each web application

  • Verify the IIS configuration of the web application

  • Verify that clients can authenticate with the web application and ensure that the Kerberos protocol is used for authentication

  • Configure the RSS Viewer web part to display RSS feeds in a local and remote web application

  • Crawl each web application and test searching content in each test site collection

Configuration checklist

Area of Configuration Description

DNS

Register a DNS A Record for the web applications networked loaded balanced (NLB) virtual IP (VIP)

Active Directory

Create a service accounts for the web applications’ IIS application pool

Register Service Principal Names (SPN) for the web applications on the service account created for the web application’s IIS application pool

Configure Kerberos constrained delegation for service accounts

SharePoint Web App

Create SharePoint Server managed accounts

Create the SharePoint Search Service Application

Create the SharePoint web applications

IIS

Validate that Kerberos authentication is Enabled

Verify Kernel-mode authentication is disabled

Install certificates for SSL

Windows 7 Client

Ensure web application URLs are in the intranet zone, or a zone configured to automatically authenticate with integrated Windows authentication

Firewall Configuration

Open firewall ports to allow HTTP traffic in on default and non-default ports

Ensure clients can connect to Kerberos Ports on the Active Directory

Test Browser Authentication

Verify authentication works correctly in the browser

Verify Logon information on the web server’s security event log

Use third party tools to confirm Kerberos authentication is configured correctly

Test SharePoint Server Search Index and Query

Verify browser access from the index server(s)

Upload sample content and perform a crawl

Test search

Test WFE Delegation

Configure RSS Feed sources on each site collection

Add RSS view web parts to the home page of each site collection

Step-by-step configuration instructions

Configure DNS

Configure DNS for the web applications in your environment. In this example we have 2 web applications, http://portal and http://teams:5555, which both resolve to the same NLB VIP (192.168.24.140/24)

For general information about how to configure DNS, see Managing DNS Records.

SharePoint Server Web apps

http://portal — Configure a new DNS A Record for the portal web application. In this example we have a host "portal" configured to resolve to the load balanced VIP.

Image of DNS record

http://teams:5555 — Configure a new DNS A Record for the for the team's web application

Image of DNS record

Note

It is important to ensure the DNS entries are A Records and not CNAME aliases for Kerberos authentication to work successfully in environments with more than one web application running with host headers and separate dedicated service accounts. See Kerberos configuration known issues (SharePoint Server 2010) for an explanation of the known issue with using CNAME with Kerberos enabled web applications.

Configure Active Directory

Next you will configure the Active Directory accounts for the web applications in your environment. As a best practice you should configure each web application to run in its own IIS application pool with its own security context (application pool identity).

SharePoint Service Application Service Accounts

In our example we have two SharePoint Server web applications running in two separate IIS application pools running with their own application pool identities.

Web Application (default zone) IIS App Pool Identity

http://portal

vmlab\svcPortal10App

http://teams:5555

vmlab\ svcTeams10App

Service Principal Names (SPNs)

For each service account, configure a set of service principal names that map to the DNS host names assigned to each web application.

Use SetSPN, a command line tool in Windows Server 2008, to configure a new service principal name. For a full explanation of how to use SetSPN, see Setspn. To learn about SetSPN improvements in Windows Server 2008, see Care, Share and Grow! : New features in SETSPN.EXE on Windows Server 2008.

All SharePoint Server web applications, regardless of port number, use the following SPN format:

  • HTTP/<DNS HOST name>

  • HTTP/<DNS FQDN>

Example:

  • HTTP/portal

  • HTTP/portal.vmlab.local

For Web applications running on non-default ports (ports other than 80/443) register additional SPNs with port number:

  • HTTP/<DNS Host Name>:<port>

  • HTTP/<DNS FQDN>:<port>

Example:

  • HTTP/teams:5555

  • HTTP/teams.vmlab.local:5555

Note

See the appendix for an explanation of why it is recommended to configure SPNs with and without port number for HTTP services running on non-default ports (80, 443). Technically the correct way to refer to a HTTP service that runs on a non-default port is to include the port number in the SPN but because of known issues described in the appendix we need to configure SPNs without port as well. Note that the SPNs without port for the teams web application does not mean services will be accessed using the default ports (80, 443) in our example.

In our example we configured the following service principal names for the two accounts we created in the previous step:

DNS Host IIS App Pool Identity Service Principal Names

Portal.vmlab.local

vmlab\svcPortal10App

HTTP/portal

HTTP/portal.vmlab.local

Teams.vmlab.local

vmlab\ svcTeams10App

HTTP/Teams

HTTP/Teams.vmlab.local

HTTP/Teams:5555

HTTP/Teams.vmlab.local:5555

To create the service principal names the following commands were executed:

SetSPN -S HTTP/Portal vmlab\svcportal10App

SetSPN -S HTTP/Portal.vmlab.local vmlab\svcportal10App

SetSPN -S HTTP/Teams vmlab\svcTeams10App

SetSPN -S HTTP/Teams.vmlab.local vmlab\ svcTeams10App

SetSPN -S HTTP/Teams:5555 vmlab\ svcTeams10App

SetSPN -S HTTP/Teams.vmlab.local:5555 vmlab\ svcTeams10App

Important

Do not configure service principal names with HTTPS even if the web application uses SSL.

In our example we used a new command line switch, -S, introduced in Windows Server 2008 that checks for the existence of the SPN before creating the SPN on the account. If the SPN already exists, the new SPN is not created and you see an error message.

If duplicate SPNs are found, you have to resolve the issue by either using a different DNS name for the web application, thereby changing the SPN, or by removing the existing SPN from the account it was discovered on.

Important

Before deleting an existing SPN, be sure it is no longer needed, otherwise you may break Kerberos authentication for another application in your environment.

Service Principal Names and SSL

It is common to confuse Kerberos Service Principal Names with URLs for http web applications because the SPN and URI formats are very similar in syntax, but it’s important to understand that they are two very separate and unique things. Kerberos service principal names are used to identify a service, and when that service is an http application, the service scheme is "HTTP" regardless if the service is access with SSL or not. This means that even if you access the web application using "https://someapp" you do not, and should not, configure a service principal name with HTTPS, for example "HTTPS/someapp".

Configure Kerberos constrained delegation for computers and service accounts

Depending on the scenario, some functionality in SharePoint Server 2010 may require constrained delegation to function properly. For example, if the RSS viewer web part is configured to display a RSS feed from an authenticated source it will require delegation to consume the source feed. In other situations it may be required to configure constrained delegation to allow service applications (such as Excel Services) to delegate the client’s identity to back-end systems.

In this scenario we will configure Kerberos constrained delegation to allow the RSS view web part to read a secured local RSS feed and secured remote RSS feed from a remote web application. In later scenarios we will configure Kerberos constrained delegation for other SharePoint Server 2010 service applications.

The following diagram conceptually describes what will be configured in this scenario:

Diagram of scenario

We have two web applications, each with their own site collection with a site page hosing two RSS viewer web parts. The web applications each have a single default zone configured to use Kerberos authentication so all feeds coming from these web sites will require authentication. In each site one RSS viewer will be configured to read a local RSS feed from a list and the other will be configured to read an authentication feed in the remote site.

To accomplish this, Kerberos constrained delegation will be configured to allow delegation between the IIS application pool service accounts. The following diagram conceptually describes the constrained delegation paths needed:

Diagram of application pool delegation

Remember that we identify the web application by service name using the Service Principal Name (SPN) assigned to the identity of the IIS application pool. The service accounts processing requests must be allowed to delegate the client identity to the designated services. All together we have the following constrained delegation paths to configure:

Principal Type Principal Name Delegates To Service

User

svcPortal10App

HTTP/Portal

HTTP/Portal.vmlab.local

HTTP/Teams

HTTP/Teams.vmlab.local

HTTP/Teams:5555

HTTP/Teams.vmlab.local:5555

User

svcTeams10App

HTTP/Portal

HTTP/Portal.vmlab.local

HTTP/Teams

HTTP/Teams.vmlab.local

HTTP/Teams:5555

HTTP/Teams.vmlab.local:5555

Note

It may seem redundant to configure delegation from a service to itself, such as the portal service account delegating to the portal service application, but this is required in scenarios where you have multiple servers running the service. This is to address the scenario where one server may need to delegate to another server running the same service; for instance a WFE processing a request with a RSS viewer which uses the local web application as the data source. Depending on farm topology and configuration there is a possibility that the RSS request may be serviced by a different server which would require delegation to work correctly.

To configure delegation you can use the Active Directory Users and Computer snap-in. Right-click each service account and open the properties dialog. In the dialog you will see a tab for delegation (note that this tab only appears if the object has an SPN assigned to it; computers have an SPN by default). On the delegation tab, select Trust this user for delegation to specified services only, then select Use any authentication protocol.

Click the Add button to add the services the user (service account) will be allowed to delegate to. To select a SPN, you will look up the object the SPN is applied to. In our instance, we are trying to delegate to a HTTP service which means we search for the service account of the IIS application pool that the SPN was assigned to in the previous step.

On the Select Users or Computers dialog box, click Users and Computers, search for the IIS application pool service accounts (in our example vmlab\svcPortal10App and vmlab\svcTeams10App), and then click OK.

You will then be prompted to select the services assigned to the objects by service principal name.

On the Add Services dialog box, click Select All then click OK. Note that when you return to the delegation dialog you don’t actually see all the SPNs selected. To see all SPNs, check the Expanded check box in the lower left hand corner.

Perform these steps for each service account in your environment that requires delegation. In our example this is the service accounts list

Configure SharePoint Server

Once Active Directory and DNS are configured, it’s time to create the web application in your SharePoint Server 2010 Farm. This paper assumes that the installation of SharePoint Server is complete at this point and the farm topology and supporting infrastructure, for instance load balancing, is configured. For more information about how to install and configure your SharePoint farm, see: Deployment for SharePoint Server 2010.

Configure managed service accounts

Before creating your web applications, configure the services accounts created in the previous steps as managed service accounts in SharePoint Server. Doing so ahead of time will allow you to skip this step when creating the web applications themselves.

To configure a managed account

  1. In SharePoint Central Administration, click Security.

  2. Under General Security click Configure managed accounts:

  3. Click Register Managed Account and create a managed account for each service account. In this example we created five managed service accounts:

    Account Purpose

    VMLAB\svcSP10Search

    SharePoint Search Service Account

    VMLAB\svcSearchAdmin

    SharePoint Search Administration Service Account

    VMLAB\svcSearchQuery

    SharePoint Search Query Service Account

    VMLAB\svcPortal10App

    Portal Web App IIS Application Pool Account

    VMLAB\svcTeams10App

    Teams Web App IIS Application Pool Account

    Note

    Managed accounts in SharePoint Server 2010 are not the same as managed service accounts in Windows Server 2008 R2 Active Directory.

Create the SharePoint Server Search Service Application

In this example we will configure the SharePoint Server Search Service Application to ensure the newly create web application can be crawled and searched upon successfully. Create a new SharePoint Server Search Web Application and place the Search, Query and Administration Services on the application server, in our example vmSP10App01. For a detailed explanation on how to configure the Search Service Application, see Step-by-Step: Provisioning the Search Service Application.

Note

The placement of all Search Services on a single application server is for demonstration purposes only. A complete discussion about SharePoint Server 2010 Search Topology options and best practices is out of scope for this document.

Create the Web Application

Browse to Central Administration and navigate to Manage Web Applications in the Application Management section. In the toolbar, select New and create your web application. Ensure that the following is configured:

  • Select Classic Mode Authentication.

  • Configure the port and host header for each web application.

  • Select Negotiate as the Authentication Provider.

  • Under application pool, select Create new application pool and select the managed account created in the previous step.

In this example, two web applications were created with the following settings:

Setting http://Portal Web Application http://Teams Web Application

Authentication

Classic Mode

Classic Mode

IIS Web Site

Name: SharePoint – Portal – 80

Port: 80

Host Header: Portal

Name: SharePoint – Teams – 5555

Port: 80

Host Header: Teams

Security Configuration

Auth Provider: Negotiate

Allow Anonymous: No

Use Secure Socket Layer: No

Auth Provider: Negotiate

Allow Anonymous: No

Use Secure Socket Layer: No

Public URL

http://Portal:80

http://Teams:5555

Application Pool

Name: SharePoint – Portal80

Security Account: vmlab\svcPortal10App

Name: SharePoint – Teams5555

Security Account: vmlab\svcTeams10App

When creating the new web application you are also create a new zone, the default zone, configured to use the Windows authentication provider. You can see the provider and it’s settings for the zone in web application management by first selecting the web application, then clicking Authentication Providers in the toolbar. The authentication providers dialog box lists all the zones for the selected web application along with the authentication provider for each zone. By selecting the zone, you will see the authentication options for that zone.

If you misconfigured the Windows settings and selected NTLM when the web application was created, you can use the edit authentication dialog for the zone to switch the zone from NTLM to Negotiate. If classic mode was not selected as the authentication mode, you must either create a new zone by extending the web application to a new IIS web site or delete and recreate the web application.

Create site collections

To test whether authentication is working correctly, you will need to create at least one site collection in each web application. The creation and configuration of the site collection will not affect Kerberos functionality, so follow existing guidance on how to create a site collection in Create a site collection (SharePoint Foundation 2010).

For this example, two site collections were configured:

Web Application Site Collection Path Site Collection Template

http://portal

/

Publishing Portal

http://teams:5555

/

Team Site

Create alternate access mappings

The portal web application will be configured to use HTTPS as well as HTTP to demonstrate how delegation works with SSL protected services. To configure SSL, the portal web application will need a second SharePoint Server alternate access mapping (AAM) for the HTTPS endpoint.

To configure alternate access mappings

  1. In Central Administration, click Application Management.

  2. Under Web Applications click configure alternate access mappings.

  3. In the Select Alternate Access Mapping Collection dropdown, select the Change Alternate Access Mapping Collection.

  4. Select the portal web application.

  5. Click Edit Public Urls in the top toolbar.

  6. In a free zone, add the https URL for the web application. This URL will be the name on the SSL certificate you will create in the next steps.

  7. Click Save.

    You should now see the HTTPS URL in the zone list for the web application.

IIS configuration

Install SSL certificates

You will need to configure an SSL certificate on each SharePoint Server hosting the web application service for each web application that uses SSL. Again, the topic of how to configure an SSL certificate and certificate trust is out of scope for this document. See the SSL Configuration section in this document for references to material about configuring SSL certificates in IIS.

Verify that Kerberos authentication is enabled

To verify that Kerberos authentication is enabled on the web site

  1. Open IIS manager.

  2. Select the IIS web site to verify.

  3. In Features View, under IIS, double click Authentication.

  4. Select Windows Authentication which should be enabled.

  5. On the right hand side under Actions, select Providers. Verify Negotiate is at the top of the list.

Verify that Kernel mode authentication is disabled

Kernel mode authentication is not supported in SharePoint Server 2010. By default, all SharePoint Server Web Applications should have Kernel Mode Authentication disabled by default on their corresponding IIS web sites. Even in situations where the web application was configured on an existing IIS web site, SharePoint Server disables kernel mode authentication as it provisions a new web application on the existing IIS site.

To verify that kernel mode authentication is disabled

  1. Open IIS manager.

  2. Select the IIS web site to verify.

  3. In Features View, under IIS, double click Authentication.

  4. Select Windows Authentication, which should be enabled.

  5. Click Advanced Settings.

  6. Verify both EAP and Kernel Mode Authentication are disabled.

Configure the firewall

Before testing authentication, ensure clients can access the SharePoint Server web applications on the configured HTTP ports. In addition, ensure clients can authenticate with Active Directory and request Kerberos tickets from the KDC over the standard Kerberos ports.

Open firewall ports to allow HTTP traffic in on default and non-default ports

Typically you have to configure the firewall on each front-end Web to allow incoming requests over ports TCP 80 and TCP 443. Open Windows Firewall with Advanced Security and browse to the following Inbound Rules:

  • World Wide Web Services (HTTP Traffic-In)

  • World Wide Web Services (HTTPS Traffic-In)

Make sure the appropriate ports are open in your environment. In our example, we access SharePoint Server over HTTP (port 80), so this rule was enabled.

In addition, we have to open the non-default port used in our example (TCP 5555). If you have web sites running on non-default ports, you also have to configure custom rules to allow HTTP traffic on those ports.

Ensure that clients can connect to Kerberos ports on the Active Directory role

To use Kerberos authentication, clients will have to request ticket granting tickets (TGT) and service tickets (ST) from the Key Distribution Center (KDC) over UDP or TCP port 88. By default, when you install the Active Directory Role in Windows Server 2008 and later, the role will configure the following incoming rules to allow this communication by default:

  • Kerberos Key Distribution Center – PCR (TCP-In)

  • Kerberos Key Distribution Center – PCR (UDP-In)

  • Kerberos Key Distribution Center (TCP-In)

  • Kerberos Key Distribution Center (UDP-In)

In your environment ensure these rules are enabled and that clients can connect to the KDC (domain controller) over port 88.

Test browser authentication

After configuring Active Directory, DNS and SharePoint Server you can now test whether Kerberos authentication is configured correctly by browsing to your web applications. When testing in the browser, ensure the following conditions are met:

  1. The test user is logged into a Windows XP, Vista, or Windows 7 computer joined to the domain that SharePoint Server is installed in, or is logged into a domain trusted by the SharePoint Server domain.

  2. The test user is using Internet Explorer 7.0 or later (Internet Explorer 6.0 is no longer supported in SharePoint Server 2010; see Plan browser support (SharePoint Server 2010)).

  3. Integrated Windows authentication is enabled in the browser. Under Internet Options in the Advanced tab, make sure Enable Integrated Windows Authentication* is enabled in the Security section:

  4. Local intranet is configured to automatically logon clients. Under Internet explorer option, in the Security tab, select Local Intranet and click the Custom level button. Scroll down and make sure that Automatic logon only in Intranet zone is selected.

    Note

    It is possible to configure automatic logon on other zones but the topic of IE security zones best practices it outside the scope of this paper. For this demonstration the intranet zone will be used for all tests.

  5. Ensure that Automatically detect intranet network is selected in Internet options->Security->Intranet Zone->Sites.

  6. If you are using fully qualified domain names to access the SharePoint Server web applications, ensure that the FQDNs are included in the intranet zone, either explicitly or by wildcard inclusion (for example, “*.vmlab.local”).

The easiest way to determine if Kerberos authentication is being used is by logging into a test workstation and navigating to the web site in question. If the user isn’t prompted for credentials and the site is rendered correctly, you can assume Integrated Windows authentication is working. The next step is to determine if the negotiate protocol was used to negotiate Kerberos authentication as the authentication provider for the request. This can be done in the following ways:

Front-end Web security logs

If Kerberos authentication is working correctly you will see Logon events in the security event logs on the front-end webs with event ID = 4624. In the general information for these events you should see the security ID being logged onto the computer and the Logon Process used, which should be Kerberos.

KList

KList is a command line utility included in the default installation of Windows Server 2008 and Windows Server 2008 R2 which can be used to list and purge Kerberos tickets on a given computer. To run KLIST, open a command prompt in Windows Server 2008 and type Klist.

If you want to purge the ticket cache, run Klist with the optional purge parameter: Klist purge

KerbTray

KerbTray is a free utility included with the Windows Server 2000 Resource Kit Tool that can be installed on your client computer to view the Kerberos ticket cache. Download and install from Windows 2000 Resource Kit Tool: Kerbtray.exe. Once you have it installed, perform the following actions:

  1. Navigate to the web sites that use Kerberos Authentication.

  2. Run KerbTray.exe.

  3. View the Kerberos Ticket cache by right clicking on the kerb tray icon in the system tray and selecting List Tickets.

  4. Validate the service tickets for the web applications you authenticated are in the list of cached tickets. In our example we navigated to the following web sites which have the following SPNs registered:

    Web Site URL SPN

    http://portal

    HTTP/Portal.vmlab.local

    http://teams:5555

    HTTP/Teams.vmlab.local

Fiddler

Fiddler is a free HTTP traffic analyzer that can be downloaded from the following location: http://www.fiddlertool.com/. In fiddler you will see the client and server negotiate Kerberos authentication and you will be able to see the client send the Kerberos Service Tickets to the server in the HTTP headers of each request. To validate that Kerberos authentication is working correctly using fiddler perform the following actions:

  1. Download and install Fiddler (www.fiddlertool.com) on the client computer.

  2. Log out of the desktop and log back in to flush any cached connections to the web server and force the browser to negotiate Kerberos authentication and perform the authentication handshake.

  3. Start Fiddler.

  4. Open Internet Explorer and browse to the web application (http://portal in our example).

You should see the requests and responses to the SharePoint Server front-end web in Fiddler.

The first HTTP 401 is the browser attempt to do the GET request without authentication. In response, the server sends back an "HTTP 401 – unauthorized" and in this response indicates what authentication methods it supports. In the next request, the client resends the previous request, but this time sends the service ticket for the web application in the headers of the request. If authenticated successfully, the server will send back the requested resource.

NetMon 3.4

NetMon 3.4 is a free network packet analyzer from Microsoft that can be downloaded from the Microsoft Download Center: Microsoft Network Monitor 3.4.

In NetMon you see all TCP request and responses to the KDC and the SharePoint Server web servers, giving you a complete view of traffic that makes up a complete authentication request. To validate that Kerberos authentication is working by using netmon, perform the following actions:

  1. Download and install NetMon 3.4 (Microsoft Network Monitor 3.4).

  2. Log out of the client then log back in to flush the Kerberos ticket cache. Optionally you can use KerbTray to purge the ticket cache by right clicking on KerbTray and selecting Purge Tickets.

  3. Start NetMon in administrator mode. Right-click the NetMon shortcut, and select Run as Administrator.

  4. Start a new capture on the interfaces that connect to the active directory controller in your environment and the web front ends.

  5. Open internet explorer and browse to the web application.

  6. After the web site renders, stop the capture and add a display filter to show the frames for Kerberos authentication and HTTP traffic.

  7. In the frames window you should see both HTTP and KerberosV5 traffic.

Test Kerberos Authentication over SSL

To clearly demonstrate the SPNs requested when a client accesses an SSL protected resource, you can use a tool like netmon to capture the traffic between client and server and examine the Kerberos service ticket requests.

  1. Either logout and then re-login into the client computer, or clear all cached Kerberos tickets by using KerbTray.

  2. Start a new NetMon capture on the client computer. Be sure to start NetMon with administrator permissions.

  3. Browse to the web application by using SSL (in this example, https://portal.)

  4. Stop the NetMon capture and examine the KerberosV5 traffic. For instructions on how to filter the capture display, see the instructions in the NetMon 3.4 section of this article.

  5. Look for the TGS request the client sends. In the request you will see the SPN requested in the "Sname" parameter.

    Note that the "Sname" is HTTP/portal.vmlab.local and not HTTPS/portal.vmlab.local.

Test SharePoint Server Search Index and Query

Verify browser access from the index server(s)

Before running a crawl, ensure that the index server can access the web applications and authenticate successfully. Log into the index server and open the test site collections in the browser. If the sites render successfully and no authentication dialogs appear, proceed to the next step. If any issues occur while accessing the sites in the browsers, go back over the previous steps to ensure all configuration actions were performed correctly.

Upload sample content and perform a crawl

In each site collection upload a "seed" document (one that is easily identifiable in search) to a document library in the site collection. For instance, create a text document containing the words "alpha, beta, delta" and save it to a document library in each site collection.

Next, browse to SharePoint Central Administration and start a full crawl on the Local SharePoint Sites content source (which should contain the two test site collections by default).

If indexing completed successfully, you should see searchable items in your index and no errors in the crawl log.

Note

If you have configured the User Profile Application (UPA) and are performing a crawl on the profile store, be sure to configure the appropriate permissions on the UPA to allow the content access account to access profile data. If you have not configured the UPA permissions you will receive errors in the crawls logs indicating the crawler could not access the profile service because it received an HTTP 401 when trying to access the service. The 401 returned is not due to Kerberos, but instead is due to the content access account not having permissions to read profile data.

Next, browse to each site collection and perform a search for the seed document. Each site collection’s search query should return the seed document uploaded.

Test front-end Web delegation

As a last step in this scenario, you use the RSS viewer web part on each site collection to ensure that delegation is working both locally and remotely.

Configure RSS feed sources on each site collection

For the portal application you have to enable RSS feeds on the Site Collection. To turn on RSS feeds follow the instructions in Manage RSS Feeds on Office.com.

Once RSS feeds are enabled, create a new custom list and add a list item for testing purposes. Navigate to the List toolbar menu and click RSS Feed to view the RSS feed. Copy the feed URL to use it in the following steps.

Perform this step for each site collection.

Add RSS view web parts to the home page of each site collection

On the portal application you’ll need to enable the SharePoint Enterprise Features site collection feature to use the RSS viewer web part. Once enabled add two RSS viewer web parts to the home page. For the first web part, configure the feed URL to point at the local RSS feed you created in the previous step. For the second web part, configure the feed URL to point at the remote feed URL. When completed, you should see both web parts successfully rendering content from the local and remote RSS feeds.