What do Office 365 Hybrids have in common?

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.

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

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.

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.

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.

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.

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.

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.

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.

Table of common elements in Microsoft 365 hybrids

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

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:

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.

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.

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