Archive

Archive for November, 2011

SharePoint 2010 and AD FS–Part 2

21 November 2011 Leave a comment

In the first part of this series we looked at the problem we were trying to solve by using these products together.  In this part we are going to look at the setup and configuration of the AD FS server.

AD FS Service Account

When you install AD FS 2.0 you have the possibility to choose between a single server AD FS or a AD FS farm (which you can add servers to). It’s a good idea to configure a farm (even if you’re going to use a single server scenario, because it provides flexibility for the future should you need it). The only difference with configuring it as a farm is that for the farm you’ll need an AD service account that has an SPN configured on it, that’s all!

So in this step we’ll create the service account and register the SPN.

  • Open AD user and computers and create a user (in this example AdfsSvc)

There a two possible ways to add the SPN to the user

  • command line : setspn -a host/logon.example.com AdfsSvc
  • GUI : Enable Advanced Features view on AD users and computers. Right-click the Service account. Select the Attribute Editor tab and scroll to servicePrincipalName and select edit. Add the SPN host/logon.example.com

ADFS 2.0 installation

Logon to the server which will function as Federation Server. Download ADFS 2.0 RTW and start the installation by running AdfsSetup.exe. Choose Federation Server.

The installation wizard will also install some additional features (.net Framework, IIS). Once installation is complete the ADFS 2.0 console will open. Do not run the configuration wizard yet.

Certificates

Besides the certificates needed for SharePoint we’ll need two certificates for ADFS 2.0 web SSO

  1. Service communications certificate.
    • This certificate is used for the logon page provided by ADFS 2.0 (in this example it’s logon.example.com).
    • This certificate should be a public certificate since you’ll be using it for employees accessing the logon page from externally
    • This should be an default SSL certificate
  2. Token signing certificate (optional, as all the traffic is already SSL it isn’t necessary to also encrypt the token.)
    • This certificate is used for signing the tokens which will be provided to SharePoint.
    • This could be a public certificate or a certificate issued by your internal Certificate Authority
    • This could be any kind of certificate. I used an SSL certificate.
    • This should be an 2048-bits certificate. 1024-bits is possible but generates a warning in ADFS 2.0

If you’re configuring a Federated Web SSO you’ll need a third certificate for decrypting (outside the scope of this post)

Since the ADFS 2.0 wizard also installed IIS you can generate certificate request from the IIS console and request your certificates.

!! Note. Always export your certificates with their private keys and save them for future issues.

Once you have your certificates installed (they should show up in IIS) you’re ready to run the ADFS 2.0 configuration wizard.

Configuration wizard ADFS 2.0

Open the ADFS 2.0 management console on the Federation Server (VSrvFs) and click ADFS 2.0 Federation Server Configuration Wizard.  This wizard will pick up the certificate and location from the default IIS website on the server, so if you want to save yourself changing the service certificate later you should go into IIS and update the bindings/certificates on that before running this wizard.

  • Create a new Federation Service
  • New federation server farm
  • Certificate : logon.example.com
  • Service Account : Use the AD service account created above (example\AdfsSvc)

Add Token signing certificate

To add certificates to ADFS 2.0 we need to disable the AD FS automatic certificate rollover feature.

Open a PowerShell prompt on the Federation Server (VSrvFs) and run the following commands

Add-PsSnapin Microsoft.Adfs.Powershell
Set-ADFSProperties -AutoCertificateRollover $false

Next, select ADFS 2.0 management console Service > Certificates > Add Token-Signing Certificate

Select the tokensigning.example.com certificate and mark it as primary.

Private key permissions

The account we specified above needs permissions on the private key of the Token signing certificate otherwise it will not be able to sign anything.  This may have already been done by the AD FS installation but lets check it anyway.

  • Open an Microsoft Management Console (mmc.exe) on the Federation Server (VSrvFs) and add the certificates snap-in (connect to local computer)
  • Browse to personal > certificates. Right-click tokensigning.example.com > All Tasks > Manage Private Keys
  • Give the service account (example\AdfsSvc) read permissions

Forms authentication

At this point you have AD FS ready to have the Relying party configured.  The default behaviour of this AD FS installation, unless you installed an AD FS Proxy, is going to be Windows Authentication rather than forms based which is probably what you are after.  This is because of the order that the authentication protocols are tried by AD FS and for some reasons that I agree with (see http://social.technet.microsoft.com/wiki/contents/articles/ad-fs-2-0-how-to-change-the-local-authentication-type.aspx and http://social.technet.microsoft.com/wiki/contents/articles/1600.aspx).

To change this to use Forms authentication first the options are in the above link they are simply:

  1. In Windows Explorer, browse to C:\inetpub\adfs\ls (assuming that inetpub lives in C:\)
  2. Select web.config and Edit in Notepad
  3. Find (Ctrl+F) <localAuthenticationTypes>
  4. There are four lines below <localAuthenticationTypes>. Each line represents one of the local authentication types listed above.
  5. Cut your preferred local authentication type (the entire line), and Paste it to the top of the list (under <localAuthenticationTypes>)
    image
  6. Save and Close the web.config file

There is no need to restart IIS as .NET will recycle the app pool when the web.config file is updated.

Customise the look

If you want to you can customise the .ASPX pages along side the web.config to give it your own look and feel. However if all you want to do is add a logo check out the appConfig section in the web.config file. It is fully commented and allows the addition of a logo with a simple change to one of the parameters.

Next Steps

So now, if you have been following these posts, you will understand the problem and have AD FS setup.  In the next post we will look at the configuration of the Relying party and the configuration within SharePoint.  I’m going to assume that you already have SharePoint 2010 installed.

Categories: SharePoint Tags: , ,

SharePoint 2010 and AD FS – Part 1

10 November 2011 Leave a comment

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:

image

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: , ,