First published on TechNet on Jul 22, 2013
Hello everyone, Jasmin here again and this time I am writing about Active Directory Federation Server (ADFS). Lately, I have been getting several questions from most of my customers and some of my peers around ADFS deployment, planning, setup, implementation etc. While addressing these questions, I realized that I was answering similar type of queries especially when it was a first time ADFS deployment effort. I have therefore created a list of common Q/A around ADFS in hopes that it would benefit those looking into federation for the first time.
What is ADFS?
ADFS helps you use single sign-on (SSO) to authenticate users to multiple web applications over the life of a single session. This is accomplished by securely sharing digital identity and rights (Claims) across security and enterprise boundaries. Some of the ADFS uses can be found here
What are the different versions of ADFS? Which one is the latest?
There are four versions of ADFS.
- AD FS 1.0 - released with Windows Server 2003 R2 as part of the operating system and could be installed as a Windows component.
- AD FS 1.1 - released with Windows Server 2008 and was carried into Windows Server 2008 R2. In both editions, AD FS was installed from the Server Manager as a role. There were minimal changes from AD FS 1.0 to AD FS 1.1.
- AD FS 2.0 was released after Windows Server 2008 R2. It was released to the web and is free to download . It requires at least Windows Server 2008 SP2 to install. Two versions (x86 and x64) are available for Windows Server 2008, while only the x64 version is available for Windows Server 2008 R2.
- ADFS 2.1 was released to Windows Server 2012 as part of the operating system and therefore, can be installed as a Role from Server Manager.
One thing to note is that, AD FS 1.x is limited in its standards support which includes WS-Federation Passive Requestor Profile (browser) and SAML 1.0 TOKENS while AD FS 2.0 extends standards support for WS-Federation. It supports WS-Federation PRP, WS-Federation Active Requestor Profile, SAML 1.1/2.0 TOKENS, SAML 2.0 Operational Modes, IdP Lite/SP Lite/eGov 1.5
What is the benefit of installing ADFS on Windows Server 2012 versus on Windows Server 2008 R2?
In Windows Server 2012, ADFS 2.1 is released as part of the operating system and is installed from the Server Manager as a role. Server Manager provides configuration wizard pages that perform validation checks and automatically install all the services that AD FS depends on. Whereas, in Windows Server 2008 SP2 or Windows Server 2008 R2, ADFS 2.0 must be installed from the web. You will also need to install the update rollup 3 for Windows Server 2008 and 2008 R2 which is located here . Furthermore, With Windows Server 2012, the AD FS server role now includes new cmdlets that you can use to perform PowerShell-based deployment within your federated identity installations and environments. Detailed cmdlets information can be found here . Lastly, with Windows Server 2012, AD FS can be integrated with Dynamic Access Control scenarios allowing AD FS to consume AD DS claims that are included in Kerberos tickets as a result of domain authentication. More information on claims can be found here
Which AD FS configuration database store should I choose, Windows Internal Database (WID) or SQL?
The AD FS configuration database stores all the configuration data. It contains information that a Federation Service requires to identify partners, certificates, attribute stores, claims, etc. You can store this configuration data in either a Microsoft SQL Server 2005 or newer database or the Windows Internal Database (WID) feature that is included with Windows Server 2008, Windows Server 2008 R2 and Windows Server 2012. Following is a short description of
|
WID Advantages |
WID Disadvantages |
|
Very easy to setup and implement |
Supports five federation servers in a farm |
|
Load balancing and fault tolerance is possible if setup as a farm. |
SAML artifact resolution and SAML/WS-Federation token replay detection feature is not available |
|
Supports multiple Federation Servers in a farm (limits to 5 federation server in a farm) |
It is not supported if there is more than 100 claim trust providers trust or more than 100 relying party trusts. |
More info: In a farm with WID as the database, the first server in the farm act as the primary server and host a read/write copy of the database. Secondary servers then replicate inbound the configuration data into their read-only database. They are fully functional federation members and can service the clients just like the Primary server. They are just unable to write any configuration changes to the WID which does not take place every day.
|
SQL Advantages |
SQL Disadvantages |
|
Supports multiple federation servers (not subject to the limitation of WID) |
Additional setup complexities. Require PowerShell to install it |
|
Load balancing and fault tolerance |
SQL cluster introduces another potential point of failure |
|
Easily Scalable |
SQL server must be performing well to service requests |
|
SAML artifact resolution and SAML/WS-Federation token replay detection supported |
If the Primary Server in the farm is down, what happens?
Another server in the farm can be configured as the primary server. Below is the PowerShell command to run on the secondary server which you want to make primary:
Add-PsSnapin Microsoft.Adfs.PowerShell
Set-AdfsSyncProperties -Role PrimaryComputer
Once the primary federation server is set run the following PowerShell commands on the other secondary federation servers to sync them with the new Primary ServersCommand to run on the other farm member servers:
Add-PsSnapin Microsoft.Adfs.Powershell
Set-AdfsSyncProperties -Role SecondaryComputer -PrimaryComputerName {FQDN of the Primary Federation Server}
Is it possible to move from WID to SQL at some point in the future?
Yes it is supported to move from WID to SQL. Detailed steps are documented here
Is SAML artifact resolution and SAML/WS-Federation token replay detection feature required by most Relying Parties?
From my experience most Relying Parties do not require this feature. However, there are some that do. So it would be wise to check on that before deciding the database configuration store. If that is a requirement, the SQL must be selected.
What is the difference between a single ADFS server versus a farm? Which one is better?
ADFS can be setup as a
- Standalone federation server.
- Farm Federation Server using WID
- Farm Federation Server using SQL
Farm federation server is definitely a better option than a standalone federation server for the obvious reasons – scalability and redundancy. Standalone federation server only support a single server and only store configuration information on a Windows Internal Database (WID). Of course It is easy to setup and its best for lab environment but lacks scalability and redundancy. Moreover, you cannot add more than one server to the Standalone federation server. However, with a farm federation server, you can start a farm with one single ADFS server and add more ADFS servers to the farm at that time or sometime in the future. I often get this question, can a farm federation server using WID function with one server? And the answer is YES! But remember you cannot benefit from load balancing and redundancy since there is only one server in the farm. For more information on Federation Server using WID or SQL please refer to the question of which database to choose.
Which type of certificates does AD FS require?
Basically you need three types of certificates.
-
Service communication certificate
- AD FS uses this certificate to enable HTTPS which is a requirement for traffic to and from the federation server and federation server proxies ( to secure communication) So it is basically a SSL certificate which needs to be installed on the IIS for each federation server and federation server proxy
-
Token signing certificate
- AD FS uses this certificate to digitally sign outgoing AD FS tokens. This is not used to secure data but in fact it is used to ensure the integrity of the security tokens as they pass between the federation servers and application server via the client computer.
-
Token decrypting certificate
- AD FS 2.0 and above has the ability to encrypt the contents of the AD FS tokens. This is in addition to having these tokens signed by the server's token signing certificate.
Where can I obtain the required certificates from?
There are several options and each have their pros and cons.
-
Server communication certificate
-
This certificate must be trusted by the client computers so it is recommended that in a production environment this certificate is obtained from a public CA. Other alternative is to use your enterprise CA (PKI) to issues this cert however, you will need to ensure that this certificate is trusted by all client computers. You may have to use Group Policy to manually push down this certificate. Bear in mind that if the client machines are not joined to the domain, they may not be able to trust your internal certificate which could result in bad user experience such as receiving security alert prompts when they try to access the federated resources. In your test environment, you can easily use a self-signed certificate if you wish as security is usually not of a concern in a lab environment.
-
-
Token Signing Certificate
-
This certificate can be issued via enterprise CA, public CA or by creating a self-signed certificate. The way it is installed depends on how you create the AD FS farm. It is required that all federation servers in the farm use the same token signing certificate. Hence you can install this certificate from the CA on a federation server and export the cert along with the private key to other federation servers in the farm and save the cost involved in obtaining a certificate from the public CA. However, the option that I personally favor is to allow what AD FS 2.x does by default i.e. it creates a self-signed certificates for signing tokens. I like this option because the maintenance is very low. It has a validity of one year after which it must be renewed however, AD FS provides the capability for automatic renewal (Automatic Certificate Rollover) for self-signed certificates before expiry and if the relying party trust is configured for automatic federation metadata, the relying party will automatically sync the new public key.
-
-
Token Decrypting Certificate
- Similar to Token Signing Certificate AD FS 2.x by default will use another self-signed certificate for the Token decrypting/encrypting certificate and as stated above, it also provides the capability for Automatic Certificate Rollover.
How can I check if my ADFS server is operating successfully?
Check for Event ID 100 under Applications and Service Logs | AD FS | Admin. This event verifies that the federation server was able to successfully communicate with the federation service.
Is there a checklist that I can follow to setup ADFS in my environment?
ADFS 2. 0 http://technet.microsoft.com/en-us/library/dd807086(v=ws.10).aspx
I also found a checklist specifically for Windows Server 2012 which is located at http://technet.microsoft.com/en-us/library/dd807086.aspx
More useful resources:
- AD FS 2.0 Step-by-Step and How to Guides: http://technet.microsoft.com/en-us/library/adfs2-step-by-step-guides(WS.10).aspx
- AD FS 2.0 Content Map: http://social.technet.microsoft.com/wiki/contents/articles/2735.ad-fs-2-0-content-map.aspx
That's it for now. As I get more questions, I will create part 2 of the ADFS FAQ.
Cheers,
Jasmin Amirali