ADFS High Availability – Quick Reference Guide for Administrators. Implement Single sign-on for Office 365.
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.
We can set up a new AD FS 2.0 infrastructure for the purpose of enabling single sign-on (SSO) with Microsoft Office 365. This will help you keep account/password management in-house.
Also, if instead of a full-fledged Single Sign-On experience, a synchronization of passwords between Office 365 and the Active Directory should suffice – then we can leverage the new Directory Synchronization tool with password synchronization.
1. Instructions for configuring Password Sync
2. Install or Upgrade the Directory Sync Tool
Single Sign On Roadmap
Single sign-on (SSO) allows you and your users to access Microsoft cloud services with your Active Directory corporate credentials. SSO requires both a security token service (STS) infrastructure and Active Directory synchronization.
You must complete the following steps in order to implement SSO:
- Step 1: Prepare for single sign-on
- Step 2: Set up your on-premises security token service
- Step 3: Set up directory synchronization
- Step 4: Verify single sign-on
Step 1: Prepare for single sign-on
To prepare, you must make sure your environment meets the requirements for SSO and verify that your Active Directory and Windows Azure Active Directory tenant is set up in a way that is compatible with single sign-on requirements. For more information, see Prepare for single sign-on.
Step 2: Set up your on-premises security token service
After you have prepared your environment for single sign-on, you will need to set up a new on-premises STS infrastructure to provide your local and remote Active Directory users with single sign-on access to the cloud service. If you currently have an STS in your production environment, you can use it for single sign-on deployment rather than setting up a new infrastructure as long as it is supported by Windows Azure AD.
Currently, Windows Azure AD supports either of the following security token services:
Active Directory Federation Services (AD FS)
For more information about how to get started with setting up an AD FS STS, follow the steps provided in Checklist: Use AD FS to implement and manage single sign-on.
Shibboleth Identity Provider
For more information about how to get started with setting up a Shibboleth STS, follow the steps provided in Use Shibboleth Identity Provider to implement single sign-on.
Other third-party identity providers
For more information about how to get started with setting up third-party identity providers for single sign-on, see Use third-party identity providers to implement single sign-on.
Step 3: Set up directory synchronization
In order for single sign-on to work properly, you must set up Active Directory synchronization as well. This includes preparing for, activating, installing a tool, and verifying directory synchronization. After you have verified directory synchronization, you activate your synced users. Using single sign-on and directory synchronization together ensures that user identities are represented correctly in the cloud service.
For more information about how to get started with setting up directory synchronization, follow the steps provided in Directory synchronization roadmap.
Step 4: Verify single sign-on
After you finish setting up your Active Directory synchronization environment, you now need to verify that your STS is functioning as expected and that single sign-on was set up correctly for your cloud service.
For more information, see either Verify and manage single sign-on with AD FS or Verify single sign-on with Shibboleth, depending on the STS type you are setting up.
Design Guide
- Understanding Key Concepts Before You Deploy AD FS 2.0
- Identifying Your AD FS 2.0 Deployment Goals
- Mapping Your Deployment Ghttps://social.technet.microsoft.com/wiki/contents/articles/1841.adfs-2-0-high-availability-and-high-resiliency-walkthrough.aspxoals to an AD FS 2.0 Design
- Determine Your AD FS 2.0 Deployment Topology
- Planning Your Deployment
- Planning Federation Server Placement
- Planning Federation Server Proxy Placement
- Planning for AD FS 2.0 Server Capacity
- Appendix A: Reviewing AD FS 2.0 Requirements
For more information about how AD FS 2.0 works and how to set up AD FS 2.0 in a test lab, see the following resources:
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}
For Steps: The Role of the AD FS Configuration Database
Summary - Determining which type of AD FS configuration database to use
AD FS 2.0 uses a database to store configuration and—in some cases—transactional data related to the Federation Service. You can use the AD FS 2.0 software to select either the built-in Windows Internal Database (WID) or Microsoft SQL Server 2005 or newer to store the data in the Federation Service.
For most purposes, the two database types are relatively equivalent. However, there are some differences to be aware of before you begin reading more about the various deployment topologies that you can use with AD FS 2.0. The following table describes the differences in supported features between a WID database and a SQL Server database.
| Feature | Supported by WID? | Supported by SQL Server? | More information about this feature | |
AD FS 2.0 features | Federation server farm deployment | Yes, with a limit of five federation servers for each farm | Yes. There is no enforced limit for the number of federation servers that you can deploy in a single farm | ||
SAML artifact resolution
| No | Yes | The Role of the AD FS Configuration Database Best Practices for Secure Planning and Deployment of AD FS 2.0 | ||
SAML/WS-Federation token replay detection | |||||
Database features | Basic database redundancy using pull replication, where one or more servers hosting a read-only copy of the database request changes that are made on a source server that hosts a read/write copy of the database | Yes | No | ||
Database redundancy using high-availability solutions, such as failover clustering or mirroring (at the database layer only)
| No | Yes | The Role of the AD FS Configuration Database High Availability Solutions Overview (https://go.microsoft.com/fwlink/?LinkId=179853) |
Note 
Note
SQL Server considerations
You should consider the following deployment facts if you select SQL Server as the configuration database for your AD FS 2.0 deployment.
- SAML features and their effect on database size and growth. When either the SAML artifact resolution or SAML token replay detection features are enabled, AD FS stores information in the SQL Server configuration database for each AD FS token that is issued. The growth of the SQL Server database as a result of this activity is not considered to be significant, and it depends on the configured token replay retention period. Each artifact record has a size of approximately 30 kilobytes (KB).
- Number of servers required for your deployment. You will need to add at least one additional server (to the total number of servers required to deploy your AD FS 2.0 infrastructure) that will act as a dedicated host of the SQL Server instance. If you plan to use failover clustering or mirroring to provide fault tolerance and scalability for the SQL Server configuration database, a minimum of two SQL servers is required.
How the configuration database type you select may impact hardware resources
The impact to hardware resources on a federation server that is deployed in a farm using WID as opposed to a federation server that is deployed in a farm using the SQL Server database is not significant. However, it is important to consider that when you use WID for the farm, each federation server in that farm must store, manage, and maintain replication changes for its local copy of the AD FS configuration database while also continuing to provide the normal operations that the Federation Service requires.
In comparison, federation servers that are deployed in a farm that uses the SQL Server database do not necessarily contain a local instance of the AD FS configuration database. Therefore, they may make slightly fewer demands on hardware resources.
Verifying that your production environment can support an AD FS 2.0 deployment
In addition to the federation servers that you will deploy, and depending on how your existing production environment is set up, the following additional servers may be required to provide the necessary infrastructure to support your new AD FS 2.0 deployment:
- Active Directory domain controller
- Certification authority (CA)
- Web server to host federation metadata
- Network load balancing (NLB)
From TechNet - Important considerations to help you plan and design which Active Directory Federation Services (AD FS) deployment topology to use in a production environment.
Determine Your AD FS Deployment Topology
AD FS Deployment Topology Considerations
Stand-Alone Federation Server Using WID
Federation Server Farm Using WID
Federation Server Farm Using WID and Proxies
Federation Server Farm Using SQL Server
The Role of the AD FS Configuration Database
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
Supported Versions of SQL: SQL 2008 R2, SQL 2012.
Checklist to setup ADFS
ADFS 2. 0 https://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 https://technet.microsoft.com/en-us/library/dd807086.aspx
More useful resources:
- AD FS 2.0 Step-by-Step and How to Guides: https://technet.microsoft.com/en-us/library/adfs2-step-by-step-guides(WS.10).aspx
- AD FS 2.0 Content Map: https://social.technet.microsoft.com/wiki/contents/articles/2735.ad-fs-2-0-content-map.aspx
What servers do I need to accommodate single sign on (SSO) aka Federated ID?
The following on premises servers are needed to accommodate SSO with Office 365:
- ADFS 2.0 Proxy Servers (2 minimum for redundancy)
- ADFS 2.0 servers (2 minimum for redundancy)
- DirSync Server
Do we require ADFS proxies or can I just deploy an ADFS internal server?
Technically, you can get away with just ADFS servers and no proxy servers for Federated ID, we recommend you deploy ADFS proxies to protect your ADFS servers and to allow for client access restriction capabilities such as denying access to email when off campus or IP filtering.
Is there an order they need to be installed?
Yes, configure ADFS and federated ID first and then Directory Sync Server. You would think it is the other way however things run better when ADFS is configured prior to Dirsync.
Do I need full blown SQL Server with ADFS?
It depends on how you are going to implement ADFS and the total number of ADFS servers deployed. If you require stretched ADFS this requires full blown SQL to accommodate this scenario or if you require more than 5 ADFS servers WID cannot scale beyond that number of ADFS servers. See here for the differences between WID and SQL with ADFS or here for topology choices for ADFS.
What versions of SQL are supported?
WID, SQL 2008 R2, SQL 2012.
How many ADFS servers do I need for Federated ID?
Each ADFS server scale varies depending on load frequency such as will everyone be logging within a 15 minute interval or spread over an hour. This answer can range from 2 ADFS servers for 15,000 users with high availability with high load or many more users depending on your load frequency.
See the ADFS sizing calculator here to help narrow it down.
Windows Server AD FS high availability configuration
While it is possible to deploy standalone Windows Server AD FS federation services, it is recommended to deploy a farm with at least two nodes for both AD FS STS and proxies for production environments.
See AD FS 2.0 Deployment Topology Considerations in the AD FS 2.0 Design Guide to decide which deployment configuration options best suit your particular needs.
|
In order to get load balancing for Windows Server AD FS endpoints on Azure, configure all members of the Windows Server AD FS farm in the same cloud service, and use the load balancing capability of Azure for HTTP (default 80) and HTTPS ports (default 443). For more information, see Azure load-balancer probe. Windows Server Network Load Balancing (NLB) is not supported on Azure. |
Note
Can I enable geo-redundancy with ADFS?
Yes, it is possible to enable this with SQL mirroring/Replication to an alternate datacenter along with geo-aware load balancers.
What happens if ADFS is unavailable?
ADFS is required to access Office 365 when using Federated ID (SSO). You want to ensure you have redundant ADFS proxies and ADFS servers to reduce any downtime to the cloud.
What type of hardware do I need for ADFS?
Make sure you do not under-spec your ADFS servers as it does require some horsepower to run effectively:
Federation Service Server
· Dual Quad Core 2.27GHz (8 cores)
· 16GB RAM
· Gigabit Network
Federation Service Proxy Server
· Quad Core 2.24GHz (4 cores)
· 4GB RAM
· Gigabit Network
Where can I get more information on deploying ADFS?
There is a good ADFS deployment guide here and a O365 ADFS deployment checklist here.
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.
Certificates' Requirements
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.
Steps - Use AD FS to implement and manage single sign-on
The following are instructions for administrators of a Microsoft cloud service who want to provide their Active Directory users with single sign-on experience by using Active Directory Federation Services (AD FS) as their preferred security token service (STS). In order to set up your on-premises STS using AD FS, complete the following steps.
Checklist: Use AD FS to implement and manage single sign-on
Deployment task |
Links to topics in this section |
||
1. Prepare for implementing SSO. |
|||
2. Review the AD FS terminology. |
|||
3. Plan your AD FS deployment. |
|||
4. Review the requirements for deploying AD FS. |
|||
5. Prepare your network infrastructure for federation servers. |
|||
6. Deploy your federation server farm. Depending on the version of AD FS that you want to use, complete the tasks in either of these checklists. |
Checklist: Deploy your federation server farm on Windows Server 2012 R2 or Checklist: Deploy your federation server farm on legacy versions of Windows Server |
||
7. Prepare your network infrastructure for configuring extranet access. |
Prepare your network infrastructure for configuring extranet access |
||
8. Configure extranet access. Depending on the version of AD FS that you want to use, complete the tasks outlined in either the following topic or checklist. |
Configure extranet access for AD FS on Windows Server 2012 R2 or Checklist: Configure extranet access for AD FS on legacy versions of Windows Server |
||
9. Install Windows PowerShell for SSO with AD FS. |
|||
10. Set up a trust between AD FS and Windows Azure AD. |
|||
11. Enabling auditing for AD FS.
|
Enabling auditing for AD FS might be beneficial in situations in which you place a high value on the security of your identity deployment and prefer to monitor it closely for suspicious or unintended activity. The process of enabling auditing for AD FS requires changes that you make using the Local Security Policy snap-in for your federation server as well as changes in the Service properties that you set using the AD FS Management console. For more information, see the "Configure Auditing for AD FS 2.0" section in Configuring Computers for Troubleshooting AD FS 2.0 |
||
12. Set up Active Directory synchronization. |
|||
13. Verify and manage your SSO implementation with AD FS. |
Warning
For more information, see Additional AD FS References.
Steps - Using WID to store the AD FS configuration database
You can create the AD FS configuration database using WID as the store by using either the Fsconfig.exe command-line tool or the AD FS Federation Server Configuration Wizard. When you use either of these tools, you can choose any of the following options to create your federation server topology. Each of these options uses WID for storing the AD FS configuration database:
- Create a stand-alone federation server
- Create the first federation server in a federation server farm
- Add a federation server to a federation server farm
If you select the stand-alone option, WID is used to store a single instance of the AD FS configuration database. This instance cannot be shared across multiple federation servers. It is meant for test lab environments only. For more information about the stand-alone federation server option or how to set one up, see Stand-Alone Federation Server Using WID or Create a Stand-Alone Federation Server.
If you select the first federation server in a federation server farm option, WID is configured for scalability that will permit additional federation servers to be added to the farm at a later time. For more information about deploying a WID farm or how to set one up, see Federation Server Farm Using WID or Create the First Federation Server in a Federation Server Farm
If you select the add a federation server option, WID is configured to replicate configuration database changes to the new federation server at set intervals. For more information about adding a federation server to a WID farm, see Federation Server Farm Using WID or Add a Federation Server to a Federation Server Farm.
|
When you deploy a federation server farm using WID, some features of AD FS may not be available. To have access to the full feature set when you configure your server farm, consider using Microsoft SQL Server to store the AD FS configuration database instead. For more information, see AD FS Deployment Topology Considerations. |
Note
Steps - Using SQL Server to store the AD FS configuration database
- The migration of an AD FS configuration database from WID to an instance of SQL Server is supported. For more information about how to do this, see AD FS: Migrate Your AD FS Configuration Database to SQL Server on the TechNet Wiki site.
- ADFS 2.0 High Availability and High Resiliency Walkthrough - https://social.technet.microsoft.com/wiki/contents/articles/1841.adfs-2-0-high-availability-and-high-resiliency-walkthrough.aspx
You can create the AD FS configuration database using a single SQL Server database instance as the store by using the Fsconfig.exe command-line tool. Using a SQL Server database as the AD FS configuration database provides the following benefits over WID:
- Administrators can leverage the high availability features of SQL Server
- It provides additional performance increases for high traffic.
- It provides feature support of SAML artifact resolution and SAML/WS-Federation token replay detection (described below).
The term "primary federation server" does not apply when the AD FS configuration database is stored in a SQL database instance because all federation servers can equally read and write to the AD FS configuration database that is using the same clustered SQL Server instance, as shown in the following illustration.
You can use SQL Server to configure two or more servers to work together as a server cluster to ensure that AD FS is made highly available to service incoming client requests. High availability provides a scale-out architecture in which you can increase server capacity by adding additional servers. Single points of failure are mitigated by automatic cluster failover.
You can achieve high availability by using the network load-balancing and failover services that SQL clustering technologies provide. For more information about how to configure SQL Server for high availability, see High Availability Solutions Overview (https://go.microsoft.com/fwlink/?LinkId=179853).
Exchange Online Support team – for any troubleshooting assistance. Please call one of the following numbers - +1 800 426 9400, +1 866 270 6179, +1 800 865 9408 (United States).
Exchange Online Support
With every Microsoft Office 365 Enterprise, Midsize Business, Small Business, Academic, and Government subscription, Microsoft Support provides global technical, pre-sales, billing and, subscription support. Support is available both online through the Office 365 portal, and by telephone for both paid and trial subscriptions. For more information, see Office 365 Support Options. Authorized administrators can use the Office 365 portal to submit service requests online, access support telephone numbers, and view all open and closed service requests. For instructions, see Contact support for technical, pre-sales, billing, and subscription issues.
Please Use the following Articles for reference,
Microsoft Support Components: https://technet.microsoft.com/en-us/library/jj945184.aspx
Office 365 for business—support options: https://office.microsoft.com/en-us/business/office-365-for-businesssupport-options-FX103843554.aspx
Support: https://technet.microsoft.com/en-us/library/jj819269.aspx
Comments
- Anonymous
January 01, 2003
Thanks & well consolidated...! - Anonymous
January 01, 2003
Thank you for getting this all together! - Anonymous
April 28, 2014
Thanks for this excellent blog post. The documentation on SSO and ADFS is scattered from a deployment perspective. Many of the wizards for deployment lack concise checklists and relevant information; for example discussing the need for HA for ADFS and DirSync. As always planning is important and it helps to have this blog post to use today. - Anonymous
May 19, 2014
Kudos to ADFS for providing such a tight system to authenticate and authorize sign in to Microsoft. Going through the post it seems having an ADFS proxy will be beneficial for anyone using ADFS internal server. - Anonymous
May 20, 2014
ADFS, neboli Active Directory Federation Services, slouží coby spojovací můstek mezi vaší - Anonymous
May 23, 2014
kódu 123307# - Anonymous
June 04, 2014
what do you mean by stretched ADFS in the section "Do I need full blown SQL Server with ADFS?" Do i need all features on both server if i am planning for merge geo replication? - Anonymous
May 11, 2015
For the Geo-Redundancy ADFS will it be an extension of ADFS instance from Primary site to DR-site or will it be a replica of production ADFS with a new ADFS instance name? - Anonymous
July 31, 2015
Thanks a lot for a wonderful article! to configure FS. www.winfotech.in