Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part II: Installing and Configuring AD FS 3.0
SharePoint

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part II: Installing and Configuring AD FS 3.0

Posted by on Friday, February 20th, 2015  

 

In my last post we took a high-level view of the various authentication processes and how they work. In this post, we’ll take the next step in our discussion of claims-based authentication and talk about Active Directory Federation Services – or AD FS, version 3.0.

Before we begin: want to read the full series from start to finish?

Part 1: The Beginning
Part 2: Installing and Configuring AD FS 3.0
Part 3: Configuring SharePoint 2013 for AD FS
Part 4: Troubleshooting
Part 5: Authentication Across Multiple Forests

Previously, we talked about the concept of an identity provider as a component of claims. AD FS is an identity provider for Windows, so it provides a Security Token Service (STS) that creates and issues SAML tokens to authenticated users.

AD FS Installation

AD FS installs as a Windows Server 2012 R2 server role and does not require any additional download. As such, the installation process is a very simple 4 or 5 steps using the “Add Roles and Features Wizard”. To start the Add Roles and Features: open the Server Manager on the server and, under the “Manage” button, select “Add Roles and Features”.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part II: Installing and Configuring AD FS 3.0

The wizard starts with an opening “Before you begin” screen that can be ignored and then produces the “Installation Type” page. In this case you will select “Role-based or feature-based installation” as shown below:

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part II: Installing and Configuring AD FS 3.0

 

On the “Select server roles” page of the Add Roles and Features Wizard, check the box for “Active Directory Federation Services”, as shown in the following image.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part II: Installing and Configuring AD FS 3.0

Once the feature installation has completed, you can click the “Close” button and proceed to the configuration of the AD FS service.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part II: Installing and Configuring AD FS 3.0

AD FS Configuration

Now that we have installed AD FS 3.0, it won’t do anything until we configure it. To do this, we need to configure the AD FS server and create the identity provider Security Token Service. We will start the process by firing off the AD FS Configuration Wizard; this can be done by clicking the Task notification under the Notifications flag of the Server Manager console.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part II: Installing and Configuring AD FS 3.0

In the first panel of the AD FS Configuration Wizard we will specify the AD account that has permissions to perform the federation service configuration. NOTE: THIS ACCOUNT MUST BE A DOMAIN ADMINISTRATOR.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part II: Installing and Configuring AD FS 3.0

In the next panel, we will specify the service properties. First we will import a wildcard SSL certificate for the service URL. I created a self-signed, wildcard SSL certificate that has been deployed to the Enterprise Trusted Root Authorities store across my farm. This addresses any potential certificate errors with my SharePoint sites.

Next, we’ll edit the default Federation Service Name of *.S7GEAR.COM so that it reads as STS.S7GEAR.COM. This will be your federation service address and will serve as the root of your signin URL.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part II: Installing and Configuring AD FS 3.0

The Specify Service Properties panel after the Federation Service name has been edited and a Federation Service display name created in the field provided is shown in the following screenshot.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part II: Installing and Configuring AD FS 3.0

VERY IMPORTANT NOTE: one of the steps that is missing in almost every walk through of this process is the requirement to have a DNS “A” record created to support the Federation Service name. Without that DNS entry SharePoint will not be able to resolve the URL and connect to the AD FS service.

In this case I need an “A” record that points my federation service, https://sts.s7gear.com, at the AD FS server IP address 192.168.239.125.

In the next panel of the wizard we specify a service account for the AD FS service. This should be a domain user account and requires no special permissions. Notice the yellow warning banner in the screenshot; this warning message is telling me I can’t use a Group Managed Service Account. This is because my test domain is not currently configured to support them. (You can see more information about Group Managed Service Accounts (gMSA) here if you’re interested.)

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part II: Installing and Configuring AD FS 3.0

AD FS 3.0 requires two databases to store configuration and artifact information and can use either the Windows Internal Database (WID) or SQL Server 2012. Both options do offer scalability although there are limitations to the use of the WID, such as the total number of federation servers allowed in the farm (5) or the lack of HA solution such as clustering or mirroring.

Database size would normally be a consideration here as well, but the amount of data stored by the AD FS related databases is actually quite small. The one thing that we would think would take up a large amount of space actually doesn’t. AD FS stores information about all of the tokens it issues in an AD FS Artifact database. While there are factors that can impact the size of the tokens being stored in the database, each artifact would normally have a size of approximately 30 KB.

In the next panel of the wizard select the type of database you would like to use by selecting either the “Create a database on this server using Windows Internal Database” or by specifying the location of the SQL Server database. (Note that if you do choose to use the WID initially, you can migrate the configuration and artifact databases to SQL at a later point in time.)

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part II: Installing and Configuring AD FS 3.0

Take the opportunity to review your selections in the next panel of the configuration wizard.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part II: Installing and Configuring AD FS 3.0

Then, if all the prerequisite checks pass, you can proceed with the configuration of the AD FS service.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part II: Installing and Configuring AD FS 3.0

Once the server has been successfully configured you can start the creation of the trusted identity provider to talk to your SharePoint farm.

 Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part II: Installing and Configuring AD FS 3.0

Now that we have finished the installation and initial configuration of AD FS we can start setting it up to talk to our SharePoint 2013 farm. This requires the completion of two tasks for now: setting up certificates to support the communications and token-signing processes and creating a relying party trust.

Certificate Export for Future Use

AD FS requires SSL for communications and will create self-signed certificates for communication, token signing, and decrypting during the installation process. For our purposes here in my development environment that is fine, but in a production environment I would recommend you purchase a wildcard certificate if you don’t already have one and use that.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part II: Installing and Configuring AD FS 3.0

For this exercise I’ve created a self-signed SSL certificate and deployed it to the Trusted Root Certification Authority of the servers in my test farm. To do that, I started by selecting the “View Certificate” option under the “Certificate” header pane on the right side of the page.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part II: Installing and Configuring AD FS 3.0

Once the certificate has opened click the “Details” tab at the top and then near the bottom click the “Copy to File…” button.

ADFS_PartII_16

This opens the Certificate Export wizard and walks us through the process of exporting the certificate to the location of our choosing.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part II: Installing and Configuring AD FS 3.0

In the first step of the Certificate Export wizard we identify whether or not we want to export the private key. In this case the option to export the private key is greyed out and not available. This is generally because of where I am attempting to export the certificate from. If I was to do this from an MMC with the certificate snap-in loaded I would be able to export the certificate with the private key.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part II: Installing and Configuring AD FS 3.0

For this export we will select the Distinguished Encoding Rules (DER) encoded binary X.509 (.CER) option. DER is the most commonly used encoding format used to store X.509 certificates in.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part II: Installing and Configuring AD FS 3.0

Browse to the location where you want to store the exported certificate and give it a recognizable name.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part II: Installing and Configuring AD FS 3.0

In the next panel you’ll complete the export wizard and when you click finish, you should get a popup message telling you that the export was successful.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part II: Installing and Configuring AD FS 3.0

Copy the resulting ADFS_Certificate.cer to a shared location on the network that is available to all the servers in the farm.

Create the Relying Party Trust

With the certificates exported we will turn our attention to creating a relying party trust. The relying party trust maintains the relationship between the federation service and SharePoint.

To create the relying party trust, we start by opening the AD FS Management console and, in the left hand panel, expanding the Trust Relationships section. In that section, select Relying Party Trusts and then right click and choose the “Add Relying Party Trust” command.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part II: Installing and Configuring AD FS 3.0

The New Relying Party Trust Wizard will open and you’ll navigate through the Welcome page to the “Select Data Source” for the trust. In our case we will select “Enter data about the relying party manually”.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part II: Installing and Configuring AD FS 3.0

Next we give our relying party trust a name. I would strongly suggest that in your production environments you add a description to the description field.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part II: Installing and Configuring AD FS 3.0

We’ll choose the AD FS Profile in the next panel. Doing so will tell AD FS to use the AD FS 2.0/3.0 version of the relying party trust configuration wizard.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part II: Installing and Configuring AD FS 3.0

We will skip the certificate configuration panel of the wizard. This is only used if you are decrypting claims tokens, which we are not. In the next panel we will configure the URL the relying party will have access to.

VERY IMPORTANT NOTE: we are checking the box to enable the WS-Federation Passive protocol. This protocol enables SAML clams authentication to SharePoint. The URL we are going to specify in the Relying party WS-Federation Passive protocol URL consists of two parts. The first is the root URL of the web application or host named site collection the relying party trust is being created for.

The second part of the URL is /_trust/ (very important that you make sure to include the trailing forward slash) so that your WS-Fed URL looks like this:

https://portal.s7gear.com/_trust/

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part II: Installing and Configuring AD FS 3.0

Next we will configure the relying party trust identifier. We will only use a single identifier, although you’re supposed to be able to have multiple identifiers associated with a single relying party. For SharePoint we use a Uniform Resource Name (URN) that is made up of 3 sections. Of the three sections the first must be urn and the other two can be whatever we want them to be as long as they match the information submitted when we create the realm (more on realms in my next post).

For our purposes the URN I am using is urn:portal:sp2013 which we will add and then remove the default https://portal.s7gear.com/_trust?

Make sure that you document the relying party trust identifier EXACTLY as it appears in the configuration. You’ll need that information later in this little exercise.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part II: Installing and Configuring AD FS 3.0

In the next panel of the wizard you could set up multi-factor Authentication (MFA); in the following screenshot you would select the radio button for “Configure multi-factor authentication settings for this relying party trust”. Selecting the radio button changes the steps the wizard is running through and adds an additional step to the process.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part II: Installing and Configuring AD FS 3.0

We aren’t configuring MFA here so our next step is to configure the Claim Issuance Authorization Rules in the following panel. We have the option to allow users to access the relying trust or we can deny all access to the relying party trust. If we deny all access to the relying party trust we will have to add issuance authorization rules that allow user access to the relying party trust.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part II: Installing and Configuring AD FS 3.0

This completes the creation of the relying party trust. Click the “Next” button to complete the wizard, making sure that the checkbox to open the “Edit Claim Rules dialog” is checked as shown below.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part II: Installing and Configuring AD FS 3.0

The final step in this part of the process is to edit the claim rules for the relying party. In other words, we are going to tell our new relying party trust which claim rule type and which LDAP attributes to send as claims. We’ll select the Attribute Store, in our case Active Directory, and then add two rules mapping an LDAP attribute to an outgoing claim type.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part II: Installing and Configuring AD FS 3.0

 

In our first rule we will map the E-Mail-Addresses LDAP attribute to the E-Mail Address outgoing claim type. In the second rule the LDAP attribute will be the User-Principal-Name, which maps to the UPN outgoing claim type.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part II: Installing and Configuring AD FS 3.0

Clicking the Finish button will complete the creation and configuration of the rules and in turn the configuration of our relying party trust.

Beginners Guide to Claims-based Authentication, AD FS 3.0, and SharePoint 2013 – Part II: Installing and Configuring AD FS 3.0

Understand that you will have to repeat the process of creating a new relying party trust for every web application or host header named site collection you create in your farm if you are using AD FS. If you are managing a large, multi-tenant farm where you are regularly creating host header named site collections it would be worth looking into scripting this with PowerShell.

So, that completes the steps necessary to install and configure AD FS 3.0 including creating a relying party trust and the associated claims rules necessary for authentication to work.

In my next post we will configure our SharePoint 2013 farm to use our AD FS instance for authentication and authorization into the farm. As always, let me know what you think in the comments section.

 

The full series:

Part 1: Claims Based Authentication, AD FS 3.0 and SharePoint 2013 Beginners Guide
Part 2: Installing and Configuring AD FS 3.0
Part 3: Configuring SharePoint 2013 for AD FS
Part 4: Troubleshooting
Part 5: Authentication Across Multiple Forests

 

Increase your efficiency using our SharePoint platform solutions.
Learn More

 

Posted by on Friday, February 20th, 2015  

Subscribe to RSS Feed

Sign Up for Newsletter

14

14

comments

    Jun 18
    2015

    Percy Jackson

    This is brilliant. Thanks for sharing

    Reply
    Sep 09
    2015

    Abhishek S

    Very Informative. Thanks

    Reply
    Sep 15
    2015

    Richard Brand

    Absolutely fantastic information – thank you for taking the time to share it.

    Reply
    Nov 02
    2015

    JRavalli

    Thank you So Much Jay !!! You are a Gentleman and a scholar. Much appreciated.

    Reply
    Jan 07
    2016

    Manuel

    Is it possible to send the user password as claim?

    Reply
      Jan 12
      2016

      Jay Simcox

      Not that I am aware of Manuel

      Thanks!

      Reply
    Feb 23
    2016

    Gabor

    HI there, have you had any experience where you would need to use multiple users from one PC? Would you be able to force Forms Based authentication (using the sign in page) for certain users, groups? Maybe using claim description? I would need that for a few relying parties only so global authentication policy can`t be a solution. thanks!

    Reply
    Apr 02
    2016

    Steve75

    Hi

    Nice article but the comment “NOTE: THIS ACCOUNT MUST BE A DOMAIN ADMINISTRATOR.” is not correct. The service account should not be a domain admin. In a test lab this is fine but it implies that it is a requirement. The account does not even need to be a local admin of the server if you setup the local security rights correctly and the ADFS service name added as a SPN to the account.

    The MS requirements can be found here:

    Reply
      Apr 02
      2016

      Steve75

      https:// Technet.microsoft.com/en-GB/library/dn554247.aspx

      Reply
      Apr 12
      2016

      Jay

      The article is referring to the account you are running the wizard as and not the service account which I assume you are referring to

      Reply

Leave a Reply