Plan your AD FS deployment
Applies To: Azure, Office 365, Power BI, Windows Intune
The first step in planning an AD FS deployment for a Microsoft cloud service is to select the right deployment topology to meet the single sign-on needs of your organization. AD FS requires that you use either Windows Internal Database (WID) or a SQL Server database to store the AD FS configuration data used by the Federation Service.
The recommended AD FS topology for the majority of Microsoft cloud services customers is to use the federation server farm with WID and proxies topology that follows. There is also an advanced option of creating a federation server farm with SQL Server proxies, mentioned later in this section.
In addition, this section also provides a table for determining the number of AD FS servers to deploy in your organization, as well as information about adding federation servers to increase performance.
Recommended topology: Federation server farm with WID and proxies
Advanced option: Federation server farm with SQL Server and proxies
Estimation table: Determine the number of AD FS servers to deploy in your organization
Adding federation servers to increase performance
Recommended topology: Federation server farm with WID and proxies
The default topology for a Microsoft cloud service is an AD FS federation server farm that consists of multiple servers hosting your organization’s Federation Service. In this topology, AD FS uses WID as the AD FS configuration database for all federation servers that are joined to that farm. The farm replicates and maintains the Federation Service data in the configuration database across each server in the farm.
The act of creating the first federation server in a farm also creates a new Federation Service. When WID is used as the AD FS configuration database, the first federation server that is created in the farm is referred to as the primary federation server. This means that this computer will be configured with a read/write copy of the AD FS configuration database.
All other federation servers configured for this farm are referred to as secondary federation servers, as they must replicate any changes that are made on the primary federation server to their read-only copies of the AD FS configuration database that they store locally.
Note
We recommend the use of at least two federation servers in a load-balanced configuration.
Setting up this base federation server farm topology is the first phase of your AD FS deployment. The second phase consists of determining how to provide access control functionality for external users by deploying either:.
Web Application proxies, if you are using AD FS in Windows Server 2012 R2
Federation server proxies, if you are using AD FS 2.0 or AD FS in Windows Server 2012
Phase 1: Deploy your federation server farm
When you are ready to start deploying your farm, you should plan on placing all of the federation servers in your corporate network behind a Network Load Balancing (NLB) host that can be configured for an NLB cluster with a dedicated cluster DNS name and cluster IP address.
Important
This cluster DNS name must match the Federation Service name (for example, fs.fabrikam.com) and be Internet-routable for the instance of AD FS that you deploy. If the name does not match, the authentication request won’t be routed to the correct DNS server or the correct federation server.
The NLB host can use the settings defined in this NLB cluster to allocate client requests to the individual federation servers. The following diagram depicts how Fabrikam, Inc. might set up the first phase of their deployment using a two-computer federation server farm (fs1 and fs2) with WID and the positioning of a DNS server and a single NLB host wired to the corporate network.
.gif "Federation Server Farm with WID")
Note
If there is a failure on this single NLB host, then users will not be able to access the cloud service. Add additional NLB hosts if your business requirements do not allow having a single point of failure.
Phase 2: Deploy your proxies
In general, proxy servers are used to redirect client authentication requests coming from outside your corporate network to the federation server farm, in other words, to configure extranet access.
Important
Depending on the version of AD FS that you want to use, you can either deploy Web Application Proxies (in AD FS in Windows Server 2012 R2) or federation server proxies (in AD FS 2.0 and AD FS in Windows Server 2012). For the definitions and the descriptions of the functions of a Web Application Proxy and a federation server proxy, see Review AD FS terminology.
For a Microsoft cloud service customer, deploying proxies in your existing AD FS infrastructure is necessary to enable the following user scenarios:
Work computer, roaming: Users who are logged on to domain-joined computers with their corporate credentials, but who are not connected to the corporate network (for example, a work computer at home or at a hotel), can access the cloud service.
Home or public computer: When the user is using a computer that is not joined to the corporate domain, the user must sign in with their corporate credentials to access the cloud service.
Smart phone: On a smart phone, to access the cloud service such as Microsoft Exchange Online using Microsoft Exchange ActiveSync, the user must sign in with their corporate credentials.
Microsoft Outlook or other email clients: The user must sign in with their corporate credentials to access their Office 365 email if they are using Outlook or an email client that is not part of Office; for example, an IMAP or POP client.
To support these user scenarios, this second phase will build on Phase 1 of the deployment discussed previously, by adding either two Web Application Proxies or two federation server proxies, providing access to a DNS server on the perimeter network, and access to a second NLB host on the perimeter network.
The second NLB host must be configured with an NLB cluster that uses an Internet-accessible cluster IP address and it must use the same cluster DNS name setting as the previous NLB cluster you configured on the corporate network for Phase 1 (fs.fabrikam.com). The Web Application Proxies or federation server proxies will also be configured with Internet-accessible IP addresses.
The following diagram shows the existing Phase 1 deployment and how Fabrikam, Inc. might provide access to a perimeter DNS server, add a second NLB host with the same cluster DNS name (fs.fabrikam.com), and add two federation server proxies (fsp1 and fsp2) to the perimeter network.
The following diagram shows the existing Phase 1 deployment and how Fabrikam, Inc. might provide access to a perimeter DNS server, add a second NLB host with the same cluster DNS name (fs.fabrikam.com), and add two Web Application Proxies (wap1 and wap2) to the perimeter network.
.gif "ADFSProxyDeploymentSSO")
Note
- You can use third-party HTTP reverse proxy solutions to publish AD FS to the extranet. For more information about how to do this, see Configuring Advanced Options for AD FS 2.0.
- All AD FS communication that travels through the firewall is based on HTTPS.
- You can create custom claim rules in AD FS that will limit your users’ access to the cloud service based on the physical location of the client computer or client device through which your user is requesting access. For more information about how to create these rules, see Limiting Access to Office 365 Services Based on Client Location.
Advanced option: Federation server farm with SQL Server and proxies
This is an advanced AD FS deployment topology option that uses web application proxies or federation server proxies and a SQL Server configuration to enable all federation servers in the farm to read and write to a common SQL Server database. Using a SQL Server database as the AD FS configuration database provides the following benefits over WID:
High-availability features of SQL Server that administrators can use.
Additional performance enhancements, including the ability to scale out using more federation servers (A WID farm has a limit of 30 federation servers if you have 100 or fewer relying party trusts. If you have more than 100 relying party trusts, a WID farm has a limit of 5 federation servers. ).
Geographic load-balancing to help provide increases for high traffic based on location.
Note
Because this topology is an advanced AD FS deployment option, the details for how this topology works and how to deploy it are not covered in this article.
For more information about this topology option, see Configuring Advanced Options for AD FS 2.0.
Estimation table: Determine the number of AD FS servers to deploy in your organization
You can use the following table to help you estimate the minimum number of AD FS federation servers and web application proxies or federation server proxies that you will need to place in a federation server farm configured with WID throughout your corporate network infrastructure based on the number of users who will require single sign-on access, including remote access, to the cloud service.
Note
All computers that will be configured for the federation server or federation server proxy role must be running either the Windows Server 2008, Windows Server 2008 R2, or Windows Server 2012 operating system. All computers that will be configure to run the Web Application Proxy role service just be running Windows Server 2012 R2 operating system.
We recommend that you use one federation server to account for redundancy. The following table follows this recommendation.
| Number of users accessing the cloud service | Minimum number of servers to deploy | Recommendation and steps |
|---|---|---|
Fewer than 1,000 users |
0 dedicated federation servers 0 dedicated proxies 1 dedicated NLB server |
For the federation servers, use two existing Active Directory domain controllers (DCs) and configure them both for the federation server role. To do this, first select two existing DCs, and then:
For NLB, configure an existing NLB host or obtain a dedicated server and then install the NLB server role on it and then configure the NLB server. For the proxies, use two existing web or proxy servers and configure them both for the federation server proxy role or the Web Application Proxy role. To do this, select two existing web or proxy servers that reside in the extranet, and then:
Note If you do not have two existing DCs and two web or proxy servers or they are not running either Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, or Windows Server 2012 R2, you should deploy dedicated servers instead, as discussed in the next row of this table. Important If you are using AD FS 2.0 or AD FS in Windows Server 2012, you must deploy and configure federation server proxies. If you are using AD FS in Windows Server 2012 R2, you can only configure and deploy Web Application Proxies. In Windows Server 2012 R2, a Web Application Proxy, a new role service of the Remote Access server role, is used to configure AD FS for extranet access. |
1,000 to 15,000 users |
2 dedicated federation servers 2 dedicated proxies |
For the federation servers, obtain two dedicated servers, and then:
For the proxies, obtain two dedicated servers that you can place in the extranet:
Important If you are using AD FS 2.0 or AD FS in Windows Server 2012, you must deploy and configure federation server proxies. If you are using AD FS in Windows Server 2012 R2, you can only configure and deploy Web Application Proxies. In Windows Server 2012 R2, a Web Application Proxy, a new role service of the Remote Access server role, is used to configure AD FS for extranet access. |
15,000 to 60,000 users |
Between 3 and 5 dedicated federation servers At least 2 dedicated proxies |
Each dedicated federation server can support approximately 15,000 users. Therefore, add an additional dedicated federation server to the base two federation server deployment described previously for every 15,000 users that will require access to the cloud service, up to a maximum of five federation servers in the farm or 60,000 users. Note An AD FS federation server farm configured to use WID supports a maximum of five federation servers. If you need more than five federation servers, you need to configure a SQL Server database to store the AD FS configuration database. For more information about this option, see Configuring Advanced Options for AD FS 2.0. |
The minimum number of users to servers recommendations provided in the previous table are calculated based on the following hardware:
| Hardware | Specifications |
|---|---|
CPU speed |
Dual Quad Core 2.27GHz CPU (8 cores) |
RAM |
4 gigabytes (GB) |
Network |
Gigabit |
Adding federation servers to increase performance
When two or more federation servers are configured in a farm using NLB technology, they can operate independently to help process the load of incoming user requests made to the AD FS Federation Service without degrading the overall performance of the service as a whole. Therefore, there is little overhead involved with adding additional federation servers to your existing production environment after you have deployed your initial federation servers strategically in your network.
Next step
Now that you have planned your AD FS deployment, the next step is to Review the requirements for deploying AD FS.