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?
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”.
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:
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.
Once the feature installation has completed, you can click the “Close” button and proceed to the configuration of the AD FS service.
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.
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.
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.
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.
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.)
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.)
Take the opportunity to review your selections in the next panel of the configuration wizard.
Then, if all the prerequisite checks pass, you can proceed with the configuration of the AD FS service.
Once the server has been successfully configured you can start the creation of the trusted identity provider to talk to your SharePoint farm.
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.
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.
Once the certificate has opened click the “Details” tab at the top and then near the bottom click the “Copy to File…” button.
This opens the Certificate Export wizard and walks us through the process of exporting the certificate to the location of our choosing.
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.
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.
Browse to the location where you want to store the exported certificate and give it a recognizable name.
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.
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.
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”.
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.
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.
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:
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.
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.
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.
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.
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.
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.
Clicking the Finish button will complete the creation and configuration of the rules and in turn the configuration of our relying party trust.
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