One of my more recent headaches has been to set up an ADFS environment on some Lab Servers to try to replicate an issue that one of our customers had on their environment. My knowledge of ADFS is average at best before this venture and trying to find good articles out there that helped was not as easy as I thought it would be. I could find several that accommodated a “Test environment” install, but what if you need to do this in production?
I hope to address some of these issues in this series of posts. There are a few resources that I used to help out here:
Firstly, Steve Peschka’s guide. Try as I might, I simply could not get things working with this guide alone, but does provide some good explanations about the steps involved:
A useful article that filled in some of the gaps I found here:
This guide is intended to be a complete step by step to help me get this right in future.
The Lab Environment
In my Lab environment I have the following Set up:
- Domain: SharePoint.Local
- All servers are joined to the SharePoint.local domain.
- AD1 – Domain Controller for SharePoint.local
- SP1 – SharePoint 2013 Server
- SQL1 – SQL Server
- ADFS1 – ADFS Server, joined to the SharePoint.local domain
Here is a visual layout of the goal here:
This is basically what we are looking to configure. We have a SharePoint 2010/2013 farm in the SharePoint.local domain. We also have an AD Domain Controller and an ADFS 2.0 server, also joined to the SharePoint.local domain.
Here is the claims process that we are looking to achieve here:
- Client browses to https://portal.contoso.com
- SharePoint receives the request and redirects the client to https://logon.contoso.com/adfs/ls
- ADFS receives the request and provides a login form for the user to enter their credentials.
- It then checks these credentials against the LDAP provider – in this case AD.
- AD authenticates the user.
- ADFS sends the claim (in our example the emailaddress,role and upn) to the client, who is then redirected back to SharePoint in step 7. SharePoint uses this claim to authenticate the user as it trusts the provider of the claim.
Besides the typical SSL certificate needed for the SharePoint Web Application, we’ll need 2 certificates for ADFS web SSO
1. Service communications certificate
a. Used for the logon page provided by ADFS 2.0 (in this example it’s logon.contoso.com).
b. This should be a public certificate since you’ll be using it for employees accessing the logon page externally
c. This should be an SSL certificate
2. Token Signing Certificate
a. This certificate is used for signing the tokens which will be provided to SharePoint. (in this example I used a self signed certificate called tokensigning.constoso.com)
b. This could be a public certificate or a certificate issued by your Internal CA
c. This can be any kind of certificate. I used an SSL certificate.
d. This should be a 2048-bits certificate. 1024-bits is fine but will generate a warning in ADFS 2.0
3. Since the ADFS 2.0 wizard also installed IIS you can generate certificate request from the IIS console and request your certificates (if you are testing in a Lab).
Note: During testing I did not manage to get this to work with Self Signed certificates so ensure you use a CA if you are testing in a lab for ALL the certificates.
DNS also needs to be configured so the client can locate the ADFS server at logon.contoso.com
This article presumes that you already have a fully functional AD, SQL and SharePoint 2010/2013 farm up and running, using the default Windows NTLM or Kerberos as the authentication method.
So the first thing we need is to have an ADFS server joined to our Domain then we can start the ADFS 2.0 installation.
1. Download the installer from http://www.microsoft.com/en-gb/download/details.aspx?id=10909
2. Run AdfsSetup.exe to begin the wizard.
3. At the Server Role screen choose Federation Server
4. Next your way through the rest of the installation.
5. Once this has completed Select Finish to Start the AD FS 2.0 Management snap-in, but do not run the Configuration wizard yet
When you install ADFS 2.0 you have the possibility to choose between a single server ADFS or a ADFS farm (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). The difference with this configuration is that for the farm config you’ll need an AD service account that has an SPN configured on it. 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 Adfs_svc)
To add the SPN to the user:
command line :
setspn -a host/logon.contoso.com Adfs_svc
ADFS 2.0 Configuration Wizard
Open the ADFS 2.0 management console on the Federation Server (VSrvFs) and click ADFS 2.0 Federation Server Configuration Wizard.
- Create a new Federation Service
- New federation server farm
- Certificate : logon.contoso.com
- Service Account : Use the AD service account created in step 3 (contoso\AdfsSvc)
- Complete the wizard
- As a test you should now be able to browse to the FederationMetadata.xml file at the following URL:
Add Token Signing Certificate
To add certificates to ADFS 2.0 we need to disable the AD FS automatic certificate rollover feature.
Open powershell on the Federation Server (VSrvFs) and run the following command:
Set-ADFSProperties -AutoCertificateRollover $false
Next, select ADFS 2.0 management console Service > Certificates > Add Token-Signing Certificate
Select the tokensigning.constoso.com certificate and mark it as primary.
Check the Certificates
A large number of problems that occur with ADFS configurations can be related to invalid Certificates. Ensure that the Certificates console is clean and that all the Certificates are valid, as well as the Root and any Intermediate Certificates. Here is what my Certificates part of the ADFS 2 console looks like:
Private Key Permissions
The account we specified in step 3 needs permissions on the private key of the Token signing certificate.
1. Open an mmc on the ADFS Server and add the certificates snap-in (connect to local computer)
2. Browse to personal > certificates. Rightclick tokensigning.contoso.com > All Tasks > Manage Private Keys
3. Give the service account (sharepoint\Adfs_Svc) read permissions
Trusted Relying Partner
In this step we’ll specify the claims we will sent to SharePoint. For SharePoint there is one unique claim identifing the user. You can send additional claims, but the unique identifier is required.
You have a choice of the unique identifier. In this example we will use the email address, but you can also use the WindowsAccountName, Common Name etc.
Open the ADFS 2.0 management console on the ADFS Server
Select Trust Relationships. Rightclick Relying Party Trusts and select Add Relying Party Trust.
Use the following settings in the wizard :
- Select Data Source : Enter data about the relying party manually
- Specify Display Name : portal.contoso.com
- Choose Profile : AD FS 2.0 profile
- Configure certificate : next (do not select a certificate)
- Configure URL : Enable support for the WS-Federation Passive protocol
- Relying party WS-Federation Passive protocol URL : https://portal.contoso.com/_trust/
- Relying party trust identifiers :
- Choose Issuance Authorization Rules : Permit all users to access this relying party
- Review settings
- Check : Open the edit Claims Rules Dialog for this relying party trust when the wizard closes
Next start the Edit Claims Rules Dialog. Select the tab Issuance Transform Rules and choose Add Rule
Use the following settings in the Add Transform Claims Rule wizard :
- Select Rule Template : Send LDAP Attributes as Claims
- Configure Rule :
- Claim Rule Name : LDAP Claims
- Attribute Store : Active Directory
- Ldap Attribute : SAM-Account-Name | Outgoing Claim Type : WindowsAccountName
Outgoing Claim Type
Token-Groups – Unqualified names
Export Token signing certificate
In the next steps we’ll need the token signing certificate to create a SpTrustedIdentityTokenIssuer in SharePoint.
Open IIS 7 manager on the Federation Server. Select the servername in the console and double-click the certificates feature. You should see the two certificates you configured earlier. Double-click the tokensigning.contoso.com certificate and select the details tab. Select copy to file.
· No do not export the private key
· DER encoded binary X.509 (.CER)
· save the file as c:\TokenSign.cer
Logon to the server running the Central Administration
Copy the tokensign.cer you exported in the previous step to c:\ (of the current server)
Open the SharePoint 2010 Management Shell (powershell) and run the following powershell script
Trusting the Certificate Chain
We need to ensure that SharePoint STS trusts the root of this CA (if it’s issued by an internal CA) so we’ll need to add the certificate. We will also add the Token Signing Certificate so that SharePoint also trusts that.
- Open the central administration website > Security > Manage Trust > Add
- Give the Trust a name (contoso RootCA) and add the Root certificate from the c:\
- Add another trust for the Token Signing Certificate
Configure the web application Authentication provider
You have options here:
- You can use a hybrid authentication of both Windows and ADFS
- You can extend the Web app to a new zone which uses the ADFS provider.
In this example I am going to extend the Web app to a new zone. This is the more common method used, but both work fine.
- Central Admin -> Application Management -> Manage Web Applications.
- Extend the Web Application.
- Ensure you select the option to Use SSL for this site.
- Select the Auth Provider (in my case Intranet zone)
- Check the Trusted Identity Provider option (in my case ADFS20)
- Hit Save (if you are using SP2013 I find this takes some time)
Site Collection Administrators
In order to test this we will add the claims user to the Site Collection admins. Make sure you use a claim here. When you open the people picker and want to specify (for example) the domain administrator and you type administrator you get two results. Select the administrator provided by ADFS20.
In my case I am using firstname.lastname@example.org so ensure you enter the full email address of the user into the people picker dialog in Central Admin, add Site collection administrators as follows:
Click on the filter for Email Address and select this test1 user – if you select the other one you will not be able to authenticate with ADFS as this represents a different user (although they are the same user in AD)
Change the ADFS login page
The ADFS default is to present a Windows popup box when the user is redirected there. This expects a login in the form of domain\user. As the user email address does not follow this pattern typically we want ADFS to present the user with a form – otherwise you may find that the user will not be able to login successfully.
- On the ADFS server:
- Open IIS Manager
- Expand the Default Site – adfs – ls
- Right-Click the site and Explore to get to the web.config folder.
Here we want to put the forms login above the Integrated login. Swap the lines so that the localauthentication section looks like this:
So we are ready to test. Ensure that both the portal.contoso.com and the logon.contoso.com domains are resolvable from your location.
To avoid certificate warnings I also installed the internal CA root certificate into my workstation.
Here is what you should see when you browse to https://portal.contoso.com
From here you will be redirected to https://logon.contoso.com/adfs/ls
The full URL is as follows:
Ensure you use the full email address in the login area.
If successful you will gain access to the site. Notice the username on the top right is the identity claim:
What’s in the claim
I have added the ClaimsViewerWebPart which shows up the details of the claim (available from:
Here we can see the claims configured for SharePoint to use:
The 2nd,3rd and 4th line show the 3 claims we configured – the email address, role (which contains the AD groups the user is a member of), and the UPN.
In the following screenshot we can see that the claim was issued by the TrustedProvider:ADFS20
The next guide will contain the set up to federate with another organisations ADFS service and configuring an ADFS2 Proxy server… coming soon.