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:

  1. Step 1: Prepare for single sign-on
  2. Step 2: Set up your on-premises security token service
  3. Step 3: Set up directory synchronization
  4. 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:

 

 

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

 

 

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

Determine Your AD FS 2.0 Deployment Topology

SAML artifact resolution

 Note

This feature is not required for Microsoft Online Services, Microsoft Office 365, Microsoft Exchange, or Microsoft Office SharePoint scenarios.

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

The Role of the AD FS Configuration Database

Database redundancy using high-availability solutions, such as failover clustering or mirroring (at the database layer only)

 Note

All AD FS 2.0 deployment topologies support clustering at the AD FS service layer.

No

Yes

The Role of the AD FS Configuration Database

High Availability Solutions Overview (https://go.microsoft.com/fwlink/?LinkId=179853)

 

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:

 

 

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.

 Note

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.

 

 

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.

Prepare for single sign-on

2. Review the AD FS terminology.

Review AD FS terminology

3. Plan your AD FS deployment.

Plan your AD FS deployment

4. Review the requirements for deploying AD FS.

Review the requirements for deploying AD FS

5. Prepare your network infrastructure for federation servers.

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.

Install Windows PowerShell for single sign-on with AD FS

10. Set up a trust between AD FS and Windows Azure AD.

Set up a trust between AD FS and Azure AD

11. Enabling auditing for AD FS.

 Warning

This is an optional step.

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.

Directory synchronization roadmap

13. Verify and manage your SSO implementation with AD FS.

Verify and manage single sign-on with AD FS

 

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.

 

 Note

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.

 

 

Steps - Using SQL Server to store the AD FS configuration database

 

  1. 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.
  2. 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

 

 

Previous blog: Office 365 Single Sign-on with ADFS: Roadmap, Design, Implementation, ADFS High Availability (& the Choice of Configuration-Database-Type for Redundancy) - Steps & FAQs

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