Office 365 Authentication

When moving to Office 365 you have various options on how to handle authentication to the service. The purpose of this article is not to explain in great detail what those options are, but rather to take a look at what considerations come into play when choosing the right option for your deployment.

Just as a short reminder, below are the options you have today. Please understand this is a somewhat simplified overview to keep things brief.

• (Pure) Cloud Identities: the username and password are stored in Azure AD. It is also Azure AD which ultimately performs the authentication (validating credentials).
• (Simple) Hybrid Identities: here, too, the username and password are stored in Azure AD. The identities, however, are synchronized from an on-premises identity store such as Active Directory. Optionally, the password (hash) from the on-premises Active Directory is synchronized too. Azure AD is responsible for performing authentication. When password hash synchronization is enabled, users also authenticate to Azure AD, but with the same password (value) as what they use in the on-premises organization. Note this experience is not a Single Sign-on experience (SSO). Users still need to enter their username and password to access Office 365.
• Federated Identities: the identities are, like hybrid identities, synchronized from an on-premises identity store. Azure AD is not responsible for performing the authentication. Instead, authentication requests are forwarded to the organization's federation solution. Typically this is an on-premises AD FS server farm, but it could also be a third-party federation solution. Federated Identities can have a full SSO-experience when the AD FS servers seamlessly authenticate the user e.g. based on their existing kerberos token (which they obtained while logging in to their computer). Today, federation is enabled per domain (UPN Suffix) and will apply to all users that share the same UPN suffix.
• Hybrid Identities with Pass-Through Authentication (PTA): This solution is somewhat comparable to federated identities. However, instead of "forwarding" the authentication request to a federation service, Azure AD will communicate with an agent that is installed in the on-premises organization. In turn, that agent communicates with the on-premises directory servers to perform the authentication. When completed, the result of the authentication is passed back to Azure AD. Users do not get SSO as they still have to type their password (so it can be transmitted to the PTA agent).
• Hybrid Identities with PTA and SSO: In addition to the previous, Azure AD now also accepts a user's kerberos token that it then forwards to the PTA agent in the on-premises organization. Just like PTA, the agent validates the token with Active Directory and confirms the authentication back result to Azure AD.

The above options can be considered the built-in options by Microsoft. Outside of these 'default' options, you can also combine various authentication options with one another. For example, some users can use a synchronized password (hash) whilst others are federated. Remember, this is only possible as long as the user accounts do not share a UPN suffix.

Next to Microsoft's solutions, 3rd-party solutions can provide alternative ways to handle identities (provisioning) and authentication. Most of the alternative authentication solutions rely on the use of federated identities where Azure AD forwards the authentication request to the third-party solution so it can perform the authentication (or forward it onwards to yet another federation solution).

Picking the Right Solution

With so many options available to you, which one should you choose? Personally, I love the idea of just using password hash synchronization because 1) it's simple to implement and 2) works great. In addition, you get the full benefits of Microsoft's built-in security features: when authentication is performed by Azure AD, you get to benefit from their intelligent password protection. Extensive machine-learning (ML) systems analyze billions of authentication requests and determine which authentications are "good" and which ones are "bad". Malicious authentication attempts are automatically blocked.

When using federated identities (e.g. with AD FS), you are responsible for detecting and blocking malicious authentication attempts yourself. Even though Microsoft has posted guidance on the matter, the protection is not as smart as Azure AD's built-in features and definitely requires more effort to setup, maintain and monitor. A lot of organizations I have worked with in the past have not (yet) deployed Smart Lockout, let alone do they have a very extensive auditing and logging on their federation solution. As such, one could argue you are less secured using AD FS, couldn't they?

The downside of using just password hash synchronization is that you don't get a SSO-experience. That, in itself, can feel a little disruptive to users. If you require an SSO-experience, yet want to benefit from Azure AD's protection, you should deploy PTA instead. PTA provides a similar experience to AD FS, but enjoys the additional protection –albeit without the detection of leaked credentials. The leaked credentials detection feature in Azure AD ensures that, when a user's password is found on the dark web's or websites selling breached/leaked data, the user is requested to update their password –this to avoid the account from being compromised if the user's credential data goes public.

All too often, I am faced with customers that believe they have nothing to hide, that they are no target, and therefore dismiss the above as less important. The reality is that almost every customer I know has suffered from some form of an attack –some of which were unfortunately successful. Even my own tenant (which includes me, myself and my wife) regularly suffers from password spray attacks... And I really don't consider myself or my wife's data to be highly valuable to anyone but ourselves. Truth is that the bad guys aren't necessarily out to get your data. With a compromised account, they can more easily spoof messages and attack other organizations which may have more interesting data than you do. But of course, there's also the ones that just do it for "fun"...

These are just a couple of examples of how (external) variables, requirements and capabilities can influence what solution is right for you. For example, you might have to abide to some regulations or internal requirements which automatically rule out the use of cloud identities. A few times, I have come across a (corporate) requirement to keep the authentication in-house. Almost always this defaults organizations to using AD FS. And whilst it does fit the profile, just remember that PTA does as well…!

Security is one thing, but there are other considerations too! Who is going to support your deployment and how? Do you have the in-house knowledge to run a fully-scalled AD FS server farm, including the (security) monitoring thereof? If the answer is no, then perhaps you should look into 'simpler' alternatives.

Am I trying to say you shouldn't use AD FS? Not entirely, no. In the end, there is not a single solution which is best for everyone. It all comes down to your (personal) requirements and expertise. However, defaulting to AD FS is rarely a good idea.

Let me perhaps give you an example of where using federated identities is actually a good idea. Perhaps it's your only option, really. Let's imagine you are already using a third-party federation solution, today. That solution is used to authenticate various other applications as well, but – more importantly – doesn't use Active Directory as it's identity provider, but your authentication is performed by (yet) another system. In such case, federating with Azure AD will allow you to continue to leverage whatever solution you have already in place. I have found this to be the most common scenario for most enterprise organizations or government entities I work with. On the flipside: they typically have the required know-how and are pretty comfortable supporting and securing such a setup too!

So, am I saying that you need to use AD FS when federating with other solutions? Not really, no. Historically many organizations might have previously deployed AD FS for that exact reason. As such, using AD FS with Azure AD is only a relatively small step to them. With the 'cloudification' that is happening, more and more applications will be cloud-native in the future. And whilst identity federation helps drive down the amount of identities you need to maintain across various systems (or at least the authentication thereof), I strongly believe you should think about moving your federation from on-premises systems to the cloud too!

Just like AD FS, you can federate solutions with Azure AD and perform authentication from there. By doing so, you might be able to do away your federation services and leverage the full power of Azure AD, and not just for Office 365. Today, Azure AD supports thousands of applications of which a lot can be enabled with a couple of clicks. And it's safe to say that the number of supported applications (both on-premises and in the cloud) will only grow as vendors adopt their solutions to integrate more easily/tightly with various cloud systems.

Know that Azure AD isn't the only system that offers such capabilities. Okta (and others) also has a great cloud-solutions, essentially offering similar capabilities. The reason why I (typically) suggest looking into Azure AD first, is because – when using Office 365 – it's already part of your deployment and you are already invested in Azure AD or are paying for some of its additional capabilities (premium licenses). As such, it's only normal that you explore the capabilities for which you are already paying ahead of selecting another solution. I'm all for maximizing existing investments over spending more money when it's not required. In the end, however, it doesn't only come down to that; you may need specific features or have requirements which cannot be fulfilled only with Azure AD.

All things considered, choosing the right option doesn't come down to authentication alone. The way you provision identities inside Azure AD, in other cloud applications and through what system you do that also determines what solution(s) you can (or should) use. Throw in the ever-changing landscape and evolution of the services, solutions and applications, and you'll find out that revisiting your authentication strategy/platform regularly is perhaps not a bad idea. It's not because, today, some features don't fit your needs, that they won't be able to tomorrow.

The only way to take a new path is to walk it. If you don't start moving federated applications to e.g. Azure AD, you'll likely end up with having to maintain a federation solution for a long(er) time. Perhaps that is your goal, perhaps it isn't. But above all, give native federation/authentication in Azure AD a try. You'll find that federating third-party (on-prem and cloud) solutions with e.g. Azure AD is simpler than it may look and that it can unlock additional scenarios to the point where you can leverage Microsoft Cloud App Security to intelligently control what actions users perform on those connected applications.

How do you perform identity lifecycle management today and what authentication solution do you use? We'd love to hear from you and get the conversation started…! - Michael

Monitor AD FS with ENow

Proactively monitor AD FS from the end-users perspective with ENow's industry leading monitoring platform. ENow monitors all of your AD FS servers and performs synthetic transactions, including performing a Single-Sign-On against Office 365 from inside your organization and outside (remote tests).