Typical extranet SharePoint deployments involve deploying SharePoint in an Active Directory (AD) forest on a perimeter network, or DMZ (see Figure 1). This solution lets you use AD as your authentication provider—without the need to create accounts for external users in your internal forest. This solution does, however, create one problem. With no trust relationship between AD domains (internal and external) you will need to create user accounts in the perimeter AD forest for not only clients and vendors, but also for internal corporate users, which obviously means more administrative work for IT departments. Using this solution, you’re managing not only two sets of accounts for internal users, but also accounts from business partners.
Figure 1. Extranet SharePoint deployment without ADFS: The figure shows a typical perimeter network setup that uses an AD forest between the internal LAN and the Internet.
This article explains how Microsoft addresses this issue using Active Directory Federation Services (ADFS). You will see how to deploy ADFS to provide a single sign-on experience for web applications across AD forests within your organization, as well as AD users in other organizations.
ADFS first appeared in Windows Server 2003 R2, but was somewhat cumbersome to set up and manage, and caused certain SharePoint features to function improperly. Microsoft has addressed these issues with SharePoint 2007 and Windows Server 2008, providing a much more seamless integration.
ADFS Deployment Design
Before you deploy ADFS you need to spend ample time planning how the infrastructure should be set up to meet your deployment goals. The design of your ADFS infrastructure will vary depending on those goals. In this article the goal is to provide a single sign-on experience for corporate users for the extranet SharePoint deployment. In other words, corporate users should be able to use their internal Active Directory account to log on to a SharePoint server that’s set up as a member server of the perimeter Active Directory forest. To accomplish that design goal, this article used the servers shown in Figure 2.
Figure 2. Extranet SharePoint Deployment with ADFS: This figure shows the arrangement of servers you need for an extranet SharePoint deployment with ADFS.
Those servers are:
- Active Directory Certificate Services or third-party public key infrastructure (PKI) (This is not required, but it is recommended for production deployments.)
- Internal LAN Active Directory Forest
- Internal LAN Account Federation Server
- Perimeter Network Active Directory Forest
- Perimeter Network SharePoint Server w/ADFS Enabled
- Perimeter Network Resource Federation Server
The rest of this article shows how to set up these servers.
ADFS Deployment
If you were one of the early explorers of ADFS you probably remember that you performed most of the ADFS setup and configuration in Windows Server 2003 R2 using the Microsoft Management Console (MMC). That process required detailed guidance to ensure the configuration was done properly. Fortunately, ADFS setup in Windows Server 2008 has been greatly improved; it now uses configuration wizards for many of the components.
After properly planning your ADFS deployment, you can install your federation servers. To install a federation server, use the “Add Roles” wizard to add the Federation Service role (see Figure 3).
Figure 3. Adding the Federation Service Role: Use the “Add Roles” wizard to add a Federation Service role.
ADFS uses SSL for federation communication, so you’ll need to obtain certificates via your own or third-party public-key infrastructure (PKI) providers. However, you can use self-signed certificates for test purposes and deployments (see Figure 4). When installing your federation server you will need both a Server Authentication Certificate and a Token Signing Certificate.
Figure 4. Selecting a Self-Signed Certificate: Because ADFS uses SSL, you’ll need a certificate, but you can use a self-signed certificate for testing purposes.
You will need to install a Federation server on both your internal LAN and in your perimeter network. According to the design scheme (see Figure 2), the internal federation server acts as the account federation server, while the perimeter federation server acts as the resource federation server.
After installing the federation servers, you need to install the ADFS Web Agent on the SharePoint server (see Figure 5). Doing that lets the SharePoint server use federation claims for authentication.
Figure 5. Adding the ADFS Web Agent to the SharePoint Server: Use the “Add Roles” wizard to add the ADFS Web Agent to your SharePoint server.
ADFS Configuration
After completing the federation server installations, you need to configure the correct settings on each one. If you used the self-signed certification option above, you will also need to install the certificate into the trusted root CA store for the computer account for each federation server and for the SharePoint server.
Configure Internal Federation Server (Account Federation Server)
You need to follow a few basic steps to configure your internal federation server. This is the server that will connect to the internal AD forest and provide tokens for users to connect to the extranet SharePoint server via their internal AD logon. These include:
- Add the Active Directory account store. This configures the federation server to provide tokens for user accounts in the designated Active Directory domain.
- Create a new organization group claim. This is a claim or identity passed to the external federation server.
- Create a new claim extraction for the group claim. This extraction maps the claim to a particular group of users within Active Directory. Members of this AD group will be given access to the extranet SharePoint server via another claim extraction set up on the resource federation server.
- Set up the resource partner. This step involves setting up the relationship between the two federation servers. Since all traffic is passed over SSL, the two servers communicate via web services. You must also specify the type of claim to pass to the resource federation server. This can be either email address, UPN, Common Name or any combination of the above. These serve as the unique identifier for each member of the claim group.
- Set up an external claim mapping. This maps the AD group to the claim being sent to the other federation partner.
Configure External Federation Server (Resource Federation Server)
Next, you need to finish setting up the external federation server. This server resides in the perimeter network with the SharePoint server. To do that, follow this procedure:
- Create a new SharePoint application. This configures ADFS to provide authentication tokens for the specified application.
- Add a new account partner. Add the URI for the account federation server. This configures the resource federation server to accept tokens from the account federation server.
- Create a new organization group claim, and map it to a resource group. This step creates a new claim and maps it to a group in the External AD forest.
- Enable the organization group claim for the SharePoint application.
- Create a new incoming claim to match the outgoing claim from the account federation server. This setting maps the two claims to each other.
SharePoint Configuration
Finally, configure your SharePoint application to support ADFS tokens by modifying the web.configfor both Central Admin and the SharePoint application sites. You need to add a new provider for both files. You can do that by manually adding the configuration information to web.config, or by using the ADFS script for SharePoint, a VBScript file that automatically updates web.config to enable SharePoint to support federation.
VBScript Route
If you choose to use the script, after running the script, make sure you log on to the SharePoint site and give access to the group claim resource group. After you do that, internal users should be able to sign on to the external SharePoint site using their internal Active Directory credentials.
Manual Route
If you prefer to modify the web.config files yourself, add the following code to the web.config file for each web application that you want to make aware of claims. Just after the section you will need to add the following lines:
<membership>
<providers>
<add name="SingleSignOnMembershipProvider2"
type="System.Web.Security.SingleSignOn.
SingleSignOnMembershipProvider2,
System.Web.Security.SingleSignOn.PartialTrust,
Version=1.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35"
fs="https://extadfs.treyresearch.com/adfs/
fs/federationserverservice.asmx" />
</providers>
</membership>
<roleManager enabled="true"
defaultProvider="AspNetWindowsTokenRoleProvider">
<providers>
<remove name="AspNetSqlRoleProvider" />
<add name="SingleSignOnRoleProvider2"
type="System.Web.Security.SingleSignOn.
SingleSignOnRoleProvider2,
System.Web.Security.SingleSignOn.PartialTrust,
Version=1.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35"
fs="https://extadfs.treyresearch.com/adfs/fs/
federationserverservice.asmx" />
</providers>
</roleManager>
Save your changes to the web.config file. At this point users should be able to sign on to the external SharePoint site using their internal Active Directory credentials.
As you’ve seen, your business can provide extranet access to SharePoint sites yet still allow internal employees access to those sites using a single signon—their internal Active Directory credentials. As organizations continue to expose SharePoint externally to provide collaboration services for clients and business partners, you can leverage Active Directory Federation Services to provide a single-sign-on experience for both external and corporate users.
Comments are closed