Home > SharePoint > SharePoint 2010 and AD FS – Part 1

SharePoint 2010 and AD FS – Part 1

There are quite a few resources out there that guide the setup of SharePoint and AD FS.  However, I’ve found it quite hard to find a guide that adequately details quite all of the necessary steps in a way that makes it clear the parts you can or should change and the reasons behind what should be considered.

This article is an attempt to merge the three or four good blogs I have discovered along with the parts that should be customised.  It draws heavily from Marc van Eijk’s blog post SharePoint 2010 and ADFS 2.0 the complete step by step guide, which is a good staring point and from Steve Peschka’s blog post Configuring SharePoint 2010 and ADFS v2 End to End which actually includes screen shots.

The basic steps I’ll follow here are:

  • Plan for installation
  • Configure ADFS
  • Configure SharePoint

Plan for installation

I’m a big fan of planning and documenting you are going to do up front, that doesn’t mean that you spend lots of time documenting everything about every system you are going to touch, but enough to enable you to have a full and complete understanding of what you are doing and how it hangs together.  Hopefully from reading this article you can do this documentation step by simply cutting and pasting this entire article and then changing the key bits to customise the installation to what you need.

Before you can configure up these products it helps to understand the problem that you are trying to solve.  Here is my take in a nutshell.

The problem

SharePoint, like any large Microsoft Enterprise solution, relies quite heavily on it being a member of a domain.  However, most setups I come across need to provide access to an external party, or parties, and the security personal do not want to add accounts for them into the domain in which SharePoint is installed.  This can cause some trouble but can usually be solved with a simple one way trust between the SharePoint and user domains, however this isn’t always possible if working in a security paranoid organisation.

The solution is provided by using a claims based system, which enables us to federate out the authentication to other parties which we trust.  In some cases this may be to a partner organisation, but it could just as easily be to a different domain which we manage as a separate entity.

The Solution

Before we get much further we need to understand a bit about claims.  There are numerous articles out there in the blogosphere that detail this so to be brief about it.  A claim is a simple fact about you, could be your name, height, email address or the like.  For this claim to be useful it has to be converted into a Token.  A Token is effectively a signed copy of your claim by a trusted authority.  Think your passport, it has a set of claims about you, name, birth date, birth location, height, eye colour and it is signed (or issued) by your Governments Internal Affairs department (or similar).

Think of it a bit like this:image

In the Internet world it is slightly different in that everything, the claim, the token, etc is an electronic stream of bits so they are physically handled somewhat differently to a passport but effectively in the same way.  The authority that issues the token is called an Secure Token Service (STS).  If that STS also provides the Identity then it is known as an Identity Provider or (IP-STS).  The consumer of the issued token is called a Relying Party (or RP) as it is relying on the STS to provide the identity if the user.  In our case, this being an article on SharePoint and AD FS, SharePoint is the RP and AD FS is the IP-STS.

The whole claims mechanism can be hard to understand so stepping back from the terms a little the solution works like this:


If you think of this the same way you’d think about logging into a site using Windows Live ID or even your universal Facebook login, or other OpenID you might have, then you know how it works from a users perspective.

Now you understand the problem domain, go through and read the rest of the articles in this series and make sure you understand what you are going to need to supply during the installation.  You’ll need to plan carefully the following:

  • The FQDN and DNS of the SharePoint web application and AD FS location.
  • The claims that you will use.

For the rest of this series we will use the following DNS and FQDN records:

  • logon.example.com    This will be the AD FS Logon server.
  • portal.example.com    This will be the main site of the SharePoint server which we are configuring.
  • my.example.com         This will be the my site location of the SharePoint farm.

As per good DNS practice all of these records will be A records to enable us to use Kerberos authentication and set SPNs.

Next Steps

In the next part of this series we will look at the setup of AD FS.


Categories: SharePoint Tags: , ,
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: