What do office 365 hybrids have in common

The concept of hybrid -- the idea that your on-premises infrastructure can branch out to include resources in the Microsoft Cloud -- exists in many Microsoft products. Hybrid is present in Microsoft 365 because of 'workloads' like Exchange Online, Skype for Business Online, and SharePoint in Microsoft 365. These are workloads that all have a kind of 'mirror-image', or 'twin', on-premises, for example, Skype for Business Online has an on-premises twin, Skype for Business Server 2015, and SharePoint in Microsoft 365 has SharePoint Server 2016.

When I talk about Microsoft 365 hybrids in the course of this article, I'm talking about connecting those twins so that they work together. So we'll talk about SharePoint hybrids, Exchange hybrids, and Skype for Business hybrids -- things that span Microsoft 365 and on-premises -- here. The goal is to make clear the technological common ground that exists in all these Microsoft 365 hybrids. In other words, we will list the building blocks of Microsoft 365 hybrids.

Hybrids

When I say Hybrid, I mean a cooperation of technologies that partner applications you own and manage in your business with those we administer in our Microsoft Cloud(s).

This definition works across not only Azure but most workloads in Microsoft 365. If you don't know what a workload is, by the way, it's an application running on the Microsoft 365 Cloud platform – Skype for Business Online, Exchange Online, and SharePoint Online are examples. 'Workload' is a way to keep them distinct from their on-premises counterparts, which is useful to keep writing and conversation from getting confusing.

Hybrid outfits use all resources at hand, no matter where they live.

Tip: Hybrid is an ever evolving technology at Microsoft, with lots of new possibilities cropping up and so there are some parts of configuring a hybrid that are more advanced to others. The capabilities of hybrid configurations are likely to grow and change from here.

On-prem hardware resources in common

All the Hybrids that I'm talking about here connect a customer environment across the Internet to Microsoft 365 (and the Azure Active Directory – AAD – in the background since it acts as the directory for Microsoft 365). The infrastructure may sound difficult to configure. Despite what you might have heard, it doesn't take a degree in 'anything-ology'. In fact, most of the hybrids work in the same way with (for the most part) the same hardware requirements.

As of 2016 here are the elements that all Hybrids need. Where things are optional, I'll say so.

All Microsoft 365 hybrid workloads have these good things:

1. Some on-prem servers (like a SharePoint farm or Skype for Business environment).

2. Active Directory on-premises where the users live or are 'homed' (in S4B terminology).

3. An Azure Active Directory Connect (AAD Connect) server (which may be on its own or combined with another server, such as WA-P). This is represented by the 'Sync' icon because AAD Connect is used to synchronize accounts from the premises to the Cloud in a hybrid.

4. [Optional] A reverse proxy server, which, in all my examples, will be Web Application Proxy (WA-P) server.

5. [Optional] You can also use Active Directory Federation Server (or ADFS).

Note: You don't need to use ADFS. AAD Connect will allow you to 'password sync' to the Cloud alongside replicating user identities. But you're not actually sending the password across the internet. You're sending a non-reversible hash of the password across a TLS secured connection.

Also, Hybrid wizards are built into each workload to help you partner with your Cloud so you can use all the tools at your disposal (no matter where they live).

If you don't have ADFS, have no compliance demands that require it, and don't want the extra complexity, don't use it. AAD Connect is designed to get the job done (and the replication interval is down from approximately 3 hours to 30 minutes, which is a helpful improvement to make).

Many large companies have some of these servers in place. Many have Active Directory domain controllers, or may have ADFS servers. If you're thinking about setting up a hybrid, you might want to check with other administrators to find out what on-premises resources are already in place. It will help you to determine whether you want to use existing infrastructure pieces, or new.

What are these servers doing?

Skip this section if you already know what these servers are doing.

Most people are accustomed to the operations of Active Directory (AD) -- how it enumerates users and objects in a domain or forest (among other things) -- and in the case of the hybrid, it is a home base for the users that will be replicated to the Microsoft Cloud. The jobs of the Sync (AAD Connect), ADFS, and WA-P (our example Reverse Proxy) are a little newer, and more central to processing hybrid HTTPS requests and identities so let's talk about those.

ADFS

To review, the job of Active Directory Federation Services is to help both sides of the hybrid to recognize one another, and by that I mean, Microsoft 365 is going to know and trust the ADFS (or ADFS cluster) that a verified public domain name belongs to. This allows single-sign-on. That means that when users with an associated UPN show up to authenticate against online resources, Microsoft 365 is going to know their UPN and what specific ADFS server to send the users to for authentication. When Heidi@contoso.com goes through the login process for Exchange Online, Microsoft 365 is going to send a request to your premises so that ADFS can intervene in authentication and either confirm she's who she claims, or deny her. This can happen quickly if the network and configuration allows it. ADFS is used if you want to leverage single sign-on: once the users login into an ADFS session, the ADFS server silently intercepts all other authentication prompts (as happens when switching between workloads, for example) to remind Microsoft 365 that you're still who you say you are. Since some IT departments have compliance or Information Security settings that require passwords stay on-premises, and some don't, ADFS is optional.

Note: No matter the hybrid workload, ADFS is only used when there is a need for Single Sign-On, or when it is non-compliant with standards or customer needs to move a password hash across the internet and into a directory outside of the company's edge firewall. It's important to note that Password Sync is turned on by default by the AAD Connect wizard in Exchange Hybrids. ADFS replies on user directories AD or ADAM (Active Directory Application Mode).

Reverse Proxy

Web Access-Proxy is a reverse proxy (RP) that has been built into Windows Server Operating systems since 2012 R2 released. A reverse proxy stands at your egress point to act on behalf of your farm. It has a 'side' that faces the internet and knows the public domain name of your Microsoft 365 hybrid, and a 'side' that faces your intranet or perimeter network and knows the domain name of your internal resources (like your SharePoint site URL, for example). It intercepts all requests coming into your business and allows you to block ports, narrow the traffic you'll accept from the Internet, and hide the internal addresses and URLs for your network from the outside world. Like all RPs, it is a proxy for internal servers on your network whenever users outside the network try to get to a resource.

SharePoint 2013 Hybrids use a reverse proxy like WA-P to intercept inbound traffic (from users in SPO making queries against an on-prem search index in the case of Search Federation), but because SharePoint 2016 Cloud Hybrids place the entire index in the cloud, the next generation no longer needs one (which is the sole reason why it's marked Optional in the diagrams). But SharePoint 2013 isn't the only place where you'll see a reverse proxy used to intercept unsolicited traffic coming from the internet. Skype for Business 2016 uses one with its Edge configuration, and Exchange 2016 uses one on its Edge as well. Since some situations require it, WA-P is optional.

Notes: 

• WA-P is used in SharePoint Hybrids (2013 Federated hybrids) to publish a SharePoint endpoint through a company's edge. WA-P intercepts calls from SPO for documents to display in Search Results, or items to display in lists that are powered by BCS or SAP. In Cloud Hybrid Search, the WA-P is only needed if you want Search Previews in your search results (you would have to publish an endpoint for Office Web Apps server through the edge). In Skype for Business, WA-P is used to intercept IM and Conference traffic from outside of the company and redirect it to the Skype for Business Edge for further processing.

• Exchange hybrid makes use of the AAD Connect tool during its hybrid wizard to give customers the option to automatically install and configure ADFS and WA-P for Exchange hybrid use , reducing the complexity you'll face when setting up a hybrid. Neither setup and configuration, nor registration of ADFS certificates is automatic to any other hybrid workload.

Sync

The graphic I use shows 'Sync' for Azure Active Directory Connect. Really, the synchronization done by AAD Connect involves the ongoing transit of users and/or user information from your on-premises and into the Cloud. AAD Connect can do two things: it replicates user accounts into Microsoft 365 (replication), and it can synchronize password information into Microsoft 365 (really it's not syncing the password, but a non-reversible hash that represents the password – synchronization). It doesn't have to 'sync your password', but it always syncs (replicates) your user accounts from Active Directory (or some filtered version of your on-premises user directory)!

AAD Connect works with healthy domain controllers in your Active Directory domain to allow for 'same sign-on' rather than ADFS's 'single sign-on'. Same sign-on means that, instead of signing in a single time and having ADFS intervene for all prompts for your session, you sign-in with the same password as on prem (and, presumably, select the option to keep yourself logged-in to reduce the number of prompts that result from navigating multiple workloads). AAD Connect for Sync is not optional.

Notes: 

• No matter the hybrid workload, all require AAD Connect. A replication and optional password synchronization of your users to Microsoft 365 (and the Azure AD behind it) is needed in all cases.

• Other similarities include that Password synchronization (used for same-sign on) also requires you to set Replicate Directory Changes and Replicate Directory Changes All in the Active Directory domains that are synchronized – do this for the on-premises account used by AAD Connect , and that you need to make a DNS A or AAAA host entry for the federation service name of an ADFS server used for SSO so that WA-P can resolve the ADFS server address internally.

Internet and Internet-available hybrid parts in common

Opposite the on-premises servers in your Microsoft 365 hybrid and across the Internet is the Microsoft Cloud, where – no matter the Microsoft 365 workload – you'll use some familiar technologies. These are:

• Public DNS records

• Public certificate authorities

• Azure Active Directory (AAD)

• Microsoft 365 (licenses/subs) and Microsoft 365 hybrid wizards

• A server-to-server (S2S) trust

• Express Route and/or Internet Traffic

• PowerShell modules

Public DNS registrars, like GoDaddy, manage and allow registration of domain names. If you want to use hybrid, you will need to register a domain name with public DNS (this may already be done for you in large companies). This domain name will be added to Microsoft 365, which will also verify that you own the public domain name you add.

Traditionally, this public domain name is the same as the Active Directory UPN attached to hybrid users on-premises, but don't get caught up on this detail. With the advent of the 'onpremisessecurityidentifier' attribute in PowerShell, which maps identity to the on-premises SID, matching the registered domain in Microsoft 365 with the UPN of users on-prem is no longer as critical as it once was. It's more important to know you'll need a public domain name that you can prove own, this public domain name will be registered in Microsoft 365 and will represent your Microsoft 365 presence on either side of the hybrid connection.

Public certificate authorities give you trustworthy SSL/TLS certificates to encrypt your network traffic. In every workload, hybrid communication takes place over an encrypted connection. You'll need a certificate from a public certificate authority on the Internet. Getting and SSL/TLS certificates is a standard practice and there are usually public certificate processes in large companies to facilitate this. In smaller companies you may need to consult your IT person, Microsoft 365 documentation, and your ISP.

Note: You may not have to apply your public certificate(s) manually. The Exchange Deployment Assistant (EDA) for Exchange Hybrids leverages Azure AD Connect to walk you through this process and register certificates for your ADFS Server (should you use an ADFS). The EDA is designed to help streamline the process of going hybrid.

Azure Active Directory, or Azure AD, is in the background when you synchronize / replicate users from your on-premises to your Microsoft 365 subscription (your Cloud premises). It's the exact same Active Directory used in wider Azure. Powerful, and seamlessly blended into Microsoft 365. You'll manage your users, and user licenses in this directory. Managing licenses in Microsoft 365 isn't done automatically by any hybrid wizard. Licenses cost customers money, so the decision of who and how many get licenses isn't made automatically.

Microsoft 365 is fully one-half of your hybrid. It has online hybrid wizards per workload. This isn't very efficient, but this is how hybrid works as of 2016 (or, in other words, as of the release of SharePoint Server 2016, Exchange Server 2016, and Skype for Business Server 2015, on-premises). But this isn't the simplest way to configure all the elements in a hybrid. A single hybrid wizard that would allow customers to choose which workloads to make hybrid, and walk-through that process per workload, as well as a hybrid command center – an Microsoft 365 Administrative dashboard – that could report whether technologies that are used by every hybrid are healthy and/or already in place doesn't yet exist.

What does this mean? It means every wizard does the same steps, and often more than once. Every wizard activates OAuth (S2S trust) for example (we'll talk about OAuth later). Some wizards, like the SharePoint Online workload's Hybrid Picker, install OAuth no matter what button you click (for every selection you make), whether OAuth is required for your hybrid scenario. Other wizards, like the Exchange hybrid wizard, set up OAuth in the background, and only once.

An S2S trust doesn't need to cross the internet, but in the case of hybrid, this trust must. An S2S isn't like a domain or forest trust. There aren't large numbers of ports to open, and no deeper integration to create between Active Directories. S2S builds a trusted connection between your on-premises SharePoint farm and a piece of the Microsoft 365 cloud called the Access Control Service or ACS (an authorization server). The trust is based upon an SSL/TLS certificate that signs tokens issued on behalf of users, that your on-premises and the Microsoft 365 ACS both agree is trustworthy – think of it like a high five between on-prem SharePoint (and its ACS proxy service) and Azure's ACS for every valid user accessing the service. Communication about user identities (the reason for this trust) is done over HTTP/443.

Note: Like with Azure AD, Microsoft 365 has a trust with Azure's ACS.

Hybrids can use self-signed or public certs here. Many large companies will choose public certificates due to their InfoSec standards – largely because the traffic crosses/may cross the Internet, an untrusted segment. For SharePoint hybrids, this certificate can be a new self-signed certificate or one extracted from the SP STS token-signing cert on-premises. (If you used a new certificate (public or self-signed) in a SharePoint hybrid you need to replace the SP STS Token-signing cert on all nodes in the SharePoint farm.)

Traffic in a hybrid leaves a client company/org, crosses the internet, and enters the Microsoft organization/Microsoft Microsoft 365 Cloud. There is a way to bypass this untrusted and uncontrolled segment, and that's by using a 3rd-party provider based Express Route from your company or organization into the Microsoft 365 Cloud. Express Route bypasses the internet by offering a private WAN connection to the Microsoft Cloud. However, it's important to realize that in cases where the WAN suffers a failure, the fallback is still the Internet.

All hybrids make use of PowerShell modules for parts of either management or configuration. The most modules you will need will likely include the Microsoft Online Services Sign-In Assistant, and the Azure Active Directory Module for Windows PowerShell. You can prep servers for the configuration and management of your Hybrids ahead of time by installing these commonly used PowerShell modules.

Ports and Protocols in common

Hybrids are ½ your on-premises, and ½ Microsoft 365 (Azure SaaS or PaaS hybrids aren't covered in this document). It's very likely both halves run on HTTPs, but at the very least, the Microsoft 365 half is 100% https/encrypted by TLS certificates, and that means it runs over standard port 443. You'll need to make sure that a public certificate is associated with traffic going out from your egress point too. That is, you will need to install a certificate on the machine doing the talking on the edge of your network – this traffic will run over 443 and be encrypted.

Note: If using ADFS, you'll actually need three certificates, one of which will be publically issued and used for the communication of services (it will live on your WA-P proxy if you choose to use ADFS), two of which will be self-signed certs made when ADFS installs, subject to automatic renewal, and are the Token-signing and Token-decryption certificates used for signing all the tokens that ADFS makes. But apart from certificates needed by an optional ADFS, all hybrids need to have an S2S certificate (sometimes called the S2S ACS Trust cert, which is too long a name).

All hybrids will use 443 (HTTPS) and 53 (DNS), by default, for hybrid traffic. Some will use additional ports like port 25 (SMTP). But the most complex case in hybrid workloads for ports is Skype for Business. Fortunately, the ports are documented.

The standout protocol used by all hybrids (apart from benchmarks used for DNS lookup, HTTPS traffic, SMTP and other standards), is OAuth (Open authorization), which is also used in Active Directory Authentication Library. It's used when a server resource on one side of the connection has to act on behalf of a user to access resources on another server, often, in the Cloud. It's a means by which the level of user access to a file or resource can be gauged for an authenticated user. This is also called 'Modern Authentication' (though OAuth refers to authorization).

All workloads use OAuth/S2S when in a hybrid (though not for every hybrid feature). Hybrid wizards generally set up this helpful protocol automatically. However, there is no unification of this effort across the workloads, no reporting of OAuth state to the customer, and no centralized way to manage this universal resource as of 2016.

In some cases, hybrid wizards turn OAuth on when it is not needed (like when SharePoint hybrid picker turns this on for OneDrive for Business redirect to the Cloud), or on every selection of a hybrid option in the wizard (again, see the SharePoint hybrid picker), or even outside of the hybrid picker in custom setup scripts, such as with Cloud Hybrid Search.

Note: You can consider the lynchpin of the hybrid to be the server-to-server (S2S) Trust between on-premises and the Cloud. It may help to be aware that S2S is Microsoft's name for its implementation of OAuth. Underlying S2S/OAuth in all of our workloads are the authentication and identity layers, both of which use Claims Authentication.

Table of common elements in Microsoft 365 hybrids

So now we have a list of common elements that looks like this:

Things hybrid workloads have in common
On-prem hardware	On-premises applications that partner with workloads in Microsoft 365 (for example Exchange Server to Exchange Online) AAD Connect Reverse Proxy (as needed) ADFS (optional)
Internet things	Public DNS records Public certificate authorities Azure Active Directory (AAD is the user directory in Microsoft 365) Microsoft 365 (E1, E3, E5 subscriptions) Microsoft 365 hybrid wizards Server-to-server (S2S) trust
Ports and protocols	HTTPS DNS S2S / OAuth

Ultimately, across all workloads the goal is to get users to be the same across boundaries so that we can simplify two of the most important functions a hybrid does – figuring out your user's identity, and what she's allowed to do with the information she's allowed to see.

A note on 'Optional'

Some of these elements are set to 'optional', but how will you know if they are needed? Some elements in Microsoft 365 hybrids are truly optional or not optional across the board:

Completely optional - all Microsoft 365 hybrids	Not optional / required by all Microsoft 365 hybrids
ADFS	AAD Connect

Inside a working hybrid there are other features that fall into a grey area. Probably the most important of these is the S2S Trust / OAuth. This trust is built by every hybrid wizard created inside of Microsoft, and the trust is built by default, even when it's not required, in order to 'future-proof' hybrids. Once you go hybrid via a wizard, this feature will be On. But (as you saw earlier) it isn't currently used in all cases.

A Reverse Proxy (WA-P in our example) is needed whenever there is an unsolicited request incoming to the customer organization for data or info (such as when using hybrid BCS, when publishing Office Web Apps or Office Online Server for document preview in search results). It's also necessary when publishing an endpoint into a DMZ of your company, such as when Exchange uses WA-P as an ADFS proxy (so if you're using ADFS in an Exchange Hybrid you will need WA-P).

Edges are needed to maintain consistent communication channels for ongoing chats in Skype for Business hybrid, and can be used to route SMTP traffic into the network from a perimeter in an Exchange Hybrid. As discussed, ADFS is used for Single-sign-on.

Must use a Reverse Proxy	Can use a Reverse Proxy (optional)	No need for a Reverse Proxy
SharePoint hybrid Inbound search SharePoint hybrid BCS Skype for Business hybrid	SharePoint Cloud hybrid (Cloud SSA) Exchange hybrid using ADFS for SSO	OneDrive for Business redirect SharePoint hybrid site features SharePoint hybrid profiles redirect Hybrid extranet redirect

There are similar tables for S2S, such as this table for SharePoint Servers in hybrid configurations. Tables like this can be built using the logic of the S2S protocol, which is used when a server resource on one side of the hybrid connection has to act on behalf of a user to access resources on another server in the Cloud.

SharePoint Hybrid Features that must use OAuth	SharePoint Hybrid Features that don't use OAuth
Hybrid Search (Outbound + Inbound) Cloud Hybrid Search (Cloud SSA) with use of Search Previews Hybrid Business Connectivity Service (BCS) Hybrid Site Features Hybrid Profiles Hybrid managed metadata	OneDrive for Business Redirection* Hybrid Extranet* Hybrid Profiles* Cloud Hybrid Search (Cloud SSA) without use of Search Previews

*The SharePoint hybrid picker will still turn on OAuth, but this is for the sake of any future hybrid configurations.