Hypothetical “best of” Solution, Employing Multi-Site Topology for ADFS, Office 365 and Azure Active Directory
Details of hypothetical “best of” solution, employing multi-site topology for ADFS, where external DNS record is controlled/updated manually when/if needed/necessary vs global load balancer solution.
To compare all available options for Office 365/Azure Active Directory authentication refer to this article and See multiple Office 365/Azure Active Directory authentication flows are described. Federated Authentication and Active Directory Authentication Library (ADAL)
All Office 365 authentication will be processed via Organizations on-premises ADFS infrastructure.
Note: Office 365 Pro-Plus and Office 2013 or greater could employ Active Directory Authentication Library (ADAL). All ADAL enabled office application will use Passive Federation. To learn more about ADAL see article Office Blog: [Introduction to ADAL based authentication]
Passive Federation (Passive Profile) — WS Fed
- Web Browsers and documents opened via SharePoint
Basic Authentication (Active Profile) — WS Trust
- Applies to clients basic Authentication (user name / password over SSL)
- ActiveSync, Outlook, IMAP, POP, SMTP, EWS
Active Federation (Metadata Exchange [MEX]) — WS Trust
- Rich Clients supporting ADFS
- Skype for Business and Office Subscriptions (Clients negotiate authentication directly with On-Prem ADFS)
AD FS Authentication Step By Step
Passive / Web Profile
- The user tries to access O365 web-based app (Outlook Web App [OWA] for example)
- The web based app requests authentication and returns redirection URL to the Authentication Platform (Azure AD)
- The Authentication Platform takes the UPN the users typed in the web-form and identifies it as a federated namespace (it looks after the @ sign). If typed namespace is federated, it returns redirection URL (endpoint) associated with company’s ADFS server.
- The ADFS server will challenge the user to authenticate via either Kerberos or NTLM and when the user is authenticated, the ADFS server issues a SAML token containing the claims with UPN and Source User ID (Immutable ID).
- The client (browser) embeds this token in the old URL and sends it to the Authentication Platform
- The Authentication Platform verifies the token and converts it to an Authentication token, which contain the UPN and now Unique ID from the Authentication Platform. This Authentication token can now be used for login
- Browser is redirected to the web-app, which now can consume the token and provides requested content
Basic Authentication / Active Profile
- The user signs into domain-joined workstation and the sign in assistant does the round-trip to get the Authentication token
- Now the user starts Outlook
- Outlook connect to Exchange Online and it will request basic authentication
- The user will get at prompt and here they need to type in there username with an UPN ex. email@example.com they can save this, but they will be prompted the first time (saves to Windows Credential Manager).
- (pre)Typed credential will be sent to EXO
- Exchange Online employs “Proxy Authentication” where it creates an impersonated representation of the user
- It then takes the domain/UPN from the basic authentication and sends it to the Authentication Platform (Azure AD)
- The Authentication Platform returns with the URL (endpoint) to the company’s ADFS server
- Exchange Online takes the basic authentication credential and sends them to the ADFS server
- The ADFS server authenticate user with the basic credentials and returns a SAML token. Claim of that token is populated with user’s UPN and Immutable ID.
- ADFS token is returned to EXO
- Exchange Online sends it to the Authentication Platform (Azure AD)
- The Authentication Platform verifies the token and converts it to/issues its own Authentication token, which still contain the user’s UPN and now Unique ID from the Authentication Platform. This authentication token is the one that EXO expects, and it can now be used for login
- Exchange Online can now authenticate the user and it will discard/dispose the memory shadow representation of the user
MEX (WS-Trust Active Profiles) Rich Client
- User signs into workstation (app/client)
- [workstation] After user’s sign-in the sign in assistant starts
- The sign-in assistant is aware of the user’s UPN and goes directly to the Authentication Platform (Azure AD)
- The Authentication Platform returns the URL to the sign-in assistant pointing to the corporate AD FS server
- The sign in assistant then goes to the AD FS server and authenticate via Kerberos or NTLM and when it is authenticated, the AD FS server gives the user an SAML token including the claims: UPN and Source User ID (Immutable ID).
- The sign in assistant presents that token to the Authentication Platform
- The Authentication Platform verifies the token and converts it to an authentication token, which contain the UPN and now Unique ID from the Authentication Platform. This authentication token can now be used for login (user is unaware of this processes).
- Now the user starts Skype for Business
- Skype for Business client connects to S4B service
- Skype for Business Online request an authentication token
- The client already has one and sends it to Skype for Business, which successfully authenticates user
ADFS client based access control
ADFS can limit connections to Office 365 and other federated resources by client type and source IP address. This capability is often used to enforce compliance regarding where and what type of client can connect to Office 365. Such functionality is achieved by analyzing ADFS header information.
Such configuration is highly dependent on having an accurate list of subnets used by end users. Often VPN connection segments are added to the subnet list to allow authorized machines to connect via a VPN and be “on the network” to allow for authorized remote access for clients outside of the corpnet firewall boundary.
Note: The effect of using client access policy has a side effect of limiting the capability of other client applications that rely on the MEX endpoint for authentication. Currently S4B, office subscription, and OneDrive Pro sync clients would need to be “on the network” or VPN to function properly if a client access policy is enabled.
Additional information on client access policy and a client access policy builder interface can be found at the following links:
[TechNet Script Center: Client Access Policy Builder]
[Download Center: Office 365 Single Sign-On with AD FS 2.0 whitepaper]
AD FS and 3rd party federation technologies
Microsoft Office 365 supports number of federation technologies to provide single sign-on. Most of non-Microsoft technologies are falling under “Works with Office 365” category. Organizations should analyze provided list of vendors and identify whether any of them are better suiting internal business needs than Microsoft’s ADFS. It is very important to note that Microsoft product group concentrates its efforts on developing new features with Microsoft technologies in mind, while working with vendors, to allow for their product(s) to be updated and compatible with newest releases of Office 365 services/software. Each vendor chooses its own development, update and support cycles/methods. It is important to understand delineation between Microsoft supported services/software and 3rd party software model, and understand that introduction of 3rd party software could present additional administrative complexities and presumably additional time associated with troubleshooting of future issues. Study links below to fully understand how 3rd party solutions are working with the service:
Office Blog: [The Works with Office 365 — Identity program now streamlined]
Summary of ADFS vs 3rd party differences:
- ADFS is part of the core Windows OS Platform (Windows Server 2012 R2) and therefore requires no additional licensing/cost (ADFS is core to Server OS)
- By installing ADFS organizations will deal with a single Vendor/Partner Support (Premier Supported)
- Most Platform Enhancements are coded for Microsoft Platform first
- Microsoft tests ADFS first, individual Vendors will be responsible to present/test their products for certification
- Isolation from other applications. Authentication will not be impacted by other applications and services
- “Connected Integration” — Identity/Federation and Office 365
Recommended AD FS topology
Note: Since all authentication traffic for Azure Active directory will be forwarded to Organization’s on-premises ADFS infrastructure, it is extremely important to ensure availability of ADFS service. Therefore, redundancy needs to be built into the on-premises ADFS infrastructure.
The following section details hypothetical “best of” solution, employing multi-site topology for ADFS, where external DNS record is controlled/updated manually when/if needed/necessary vs global load balancer solution:
Building ADFS farm to scale
(Hardware Sizing) contains the hardware requirements for each ADFS server. Once number of servers is identified and networking location and topology is known, each server and proxy should be provisioned. Organizational standard windows image should be used on each server to simplify future support
Establishing DR procedures for federation
Federation severs will become pivotal key-point of your Office 365 infrastructure. The absolute dependency on federation servers to be up-time and available is paramount to provide users with access to Office 365. By choosing to implement federated identity Organization is choosing to take full responsibility to authenticate every user, every device every time transitionally. Therefore, adequately sized, configured, and always-on federation infrastructure is a pivotal part of the Office 365 deployment. Understanding its functionality, redundancy levels and creating/adjusting internal DR procedures should be a part of this deployment at earliest possible time.
Using Windows Azure to host federated infrastructure
To provide additional redundancy and remove dependency of Organization’s infrastructure, installation of federation servers in Windows Azure is possible. Such topology could be beneficial if multi-site/geo-redundancy is difficult to achieve on-premises. By locating some/all federation sever(s) and/or domain controllers into the Windows Azure and establishing failover mechanism allowing users to fell over to the Windows Azure hosted instance (or in reverse to on-premises hosted site) when needed should provide additional resiliency. Note that virtual machines that are hosted in Windows Azure will consume processor and network units.
Choosing between WID and SQL database for ADFS deployment
The configuration database is one of the components that make part of an AD Federation Server deployment. It contains all configuration data regarding the Federation Service and includes information the Federation Services needs to identify certificates, claims etc. One of the decisions related to an ADFS deployment is whether to use SQL or a Windows Internal Database (WID) to store the ADFS configuration database in. In order to process identity/authorization requests, ADFS needs an active (live) connection to the database. To be clear, there is no caching happening, which means that the federation server will stop processing requests from the moment the connection to the database is lost. This is an important point, and why Microsoft strongly recommend the use of WID.
Why is this important? This means that the availability of the federation service also depends on the availability of the database. The choice of the database type directly affects what options you can leverage. When it comes to Office 365, this guidance helps us to dictate how you should setup your federation server infrastructure. When we look at Office 365, here is what we feel are the relevant differences between SQL and the Windows Internal Database when used as configuration database store for AD FS:
Windows Internal Database
Limited to 30 servers in the farm
built-in “replication” mechanism
Needs SQL cluster
SAML artifact resolution & SAML/WS-Federation token replay detection
As you can see, there are only small differences. Obviously, if you need some of the advanced features you’ll only have one option: SQL. On the other hand, ADFS & Office 365 does not use any of these advanced features leaving the WID also as a valid choice. To justify Microsoft recommendation, lets evaluate some of the claims against the Windows Internal Database.
Deployment, Management and High Availability
When using SQL, all your ADFS servers will be connecting to a central database. This means you only have to manage a single database instance. However; if you want to have some sort of high-availability, you’ll have to defer to clustered SQL servers. This not only leads to more servers, but also to an increased complexity. With WID, High Availability comes built-in into the product. The first ADFS server that you install will automatically become the “primary” server. Any subsequent ADFS server that you add to the farm will start replicating changes from the primary configuration database. This is an automatic process that polls for changes every 5 minutes:
The ADFS Design guide states that SQL could be used to achieve a better performance. The thought behind this is that when using the WID, you’re actually using a tiny local SQL database which consumes more resources on the ADFS server, and by moving the database off the server to a dedicated SQL server — this will save you some of these resources. In testing, and production deployments Microsoft have continued to compare functionality across both SQL and WID, the load on the SQL server was — even when the ADFS server(s) were under high pressure — never really very high.
From an Office 365 perspective, there has not been any significant load on the SQL server.
This is perhaps the one point where the WID definitely lacks in functionality behind SQL. Yet in recommendation, Microsoft see it as a benefit rather than a deficiency. In the event of a failure of your primary federation server, your only option is to restore that “primary” configuration database, reactivating the replication between the different members of the federation server farm. Until the database is back up and running, you will not be able to make any changes to your farm’s configuration. This automatically means that you have to take backups of your primary federation server (system state) at least every time you make a configuration change. Comparing this to the backup process of SQL (daily full or event incremental) that might be going on, this is definitely an additional effort in maintaining the environment. In addition, when using SQL it is important to understand that there is no “primary” federation server: a failed server can easily be replaced by adding a new member in the farm.
SAML Artifact Resolution
While SAML artifact resolution is not used by Office 365 or most of the other application, which makes WID deployment (if/when fits due to the number of the servers in the deployment) recommended way deploying ADFS. SAML artifact resolution is an alternate SAML flow where the IdP sends an artifact of the token to the RP, instead of the whole token. The RP then goes back to the IdP on its own and sends it a request for the rest of the token out of band. The IdP sends the rest of the token directly to the RP without user involvement in the flow. In this flow, every ADFS server has to be able to write to the database in order to store the token for later retrieval by the RP, which is why WID can’t be used here. Overall this is very uncommon type of deployment/requirement.
Token Replay Detection
Token replay detection is only useful when ADFS will be fulfilling the role of a service provider security token service (SP-STS). In the context of AAD and O365, a customer should only be concerned with this if they are planning to configure AD FS for partner authentication to relying party applications via another trusted identity provider. Technically, AAD and O365 could fit in that category if Organization is planning to synchronize partner’s identities to Organization’s tenant and configure ADFS to bounce to a third-party IdP for passive authentication of those identities, but that’s a very niche scenario. Therefore, if ADFS is “the end of the line” for user’s authentication request, then TRD is out of the picture.
Generally, Microsoft advocate simplicity over complexity when/if possible and therefore their standing recommendation to deploy WID as ADFS’s back-end. Naturally, both SQL and WID are fully supported methods to deploy ADFS, therefore it comes to a technical choice and features required by Organization as well as wiliness to support one or another topology over prolonged period of time.