Udostępnij za pośrednictwem

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

  • Artykuł

 

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.

 

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

 

 

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.

 
 

 

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).

Comments