Perhaps the least understood of all the Office 365 features is the Active Directory Federation Services (ADFS). Even though it is not widely used, ADFS will probably become an essential technology as more and more organizations begin hosting applications in the cloud. It solves one of the biggest headaches with BPOS – password management.

We wanted to take the opportunity to introduce you to the DFS. As we do, we will explain what the services do, why they are useful, and also provide a brief overview of how they work.

An Overview

The ADFS allows for the sharing of identity information between trusted partners beyond the boundary of an AD forest. This secure sharing of identity information is known as federation.

So why is federation important? Simply put, it provides a means for users to use the current AD username and password to access Office 365. For your users, this means they either won’t be prompted for credentials when accessing Office 365 services, or will be prompted to provide their local AD credentials to access the Office 365 services. For administrators, this means your password policy (age, length, complexity, etc.) will be controlled through your local AD.

Identity Management

The need for the ADFS all comes down to identity management and trust. To illustrate this point, imagine that you needed to fly to Las Vegas for a conference. When you go through security at the airport, you will be expected to show you driver’s license. Airport security don’t trust you to tell the truth about who you are, but they do trust your state authorities to verify your identity, before issuing your license. As such, the security officers at the airport trust the information on you driver’s license because they trust the agency that issued it to you.

When the ADFS is used for web single sign-on, things work in a similar way. The end user’s identity isn’t directly verified by the cloud provider. Instead, the user logs into the AD, just as they always have. This is the only time that the user will be prompted to enter a username and a password.

The user can be seamlessly logged into the hosted application because a trusted partnership exists between the organization and the cloud provider. As a part of this partnership, the cloud provider trusts the organization to verify the identity of each user through the initial authentication process.

When a user attempts to access a hosted application, they are referred back to their local ADFS server, which then authenticates them, and issues a login token. The login token is sent by the client to the cloud service provider. Once the provider receives a claim, and validates it as being trustworthy, they can extract the user’s information and map it to their own identity management system. This allows the user to access the web application, without having to directly authenticate into the cloud provider’s network.

Video Overview

The video below provides a conceptual overview of how a user is authenticated to the Office 365 service when ADFS is enabled on a domain. Remember that this is just to give you a conceptual overview, which shows how an OWA user accesses the servers. The actual process varies, based on how you connect (inside the nework/outside the network, Outlook/OWA/Mobile device, etc). Other articles in this series go into more depth.

Was this article helpful?