Do I really need ADFS?

Update 2018-01-06: Lots of new things came up so I updated this article.
Update 2018-04-10: Few updates again, thanks to your contributions!  

I often hear and read misconceptions on whether or not you should or must deploy an ADFS farm when Office 365 is in the picture. So I will try to give you my version (well it is a collection of feedback from my peers as well), hoping that might help you to sort out your thoughts.

ADFS and Office 365

Even when you have deployed an ADFS farm as a part of your Office 365 adoption, your ADFS farm doesn't trust Office 365. Your ADFS farm trusts Azure Active Directory. It seems that I am just being finicky with the wording but it has its importance. You can use Azure AD without using any of the workloads of Office 365. Although we sometimes use that shortcut, keep in mind that ADFS is in fact trusting your Azure Active Directory.

ADFS and Azure AD Connect

Those are two different things. They do not talk to each other, they have their own database... The only thing they have in common is that they are domain joined. That is about it.

Why do I need ADFS to use Office 365 or Azure AD?

Well, you don't. The primary reason why you want ADFS deployed in conjunction with your Office 365 deployment or your Azure AD is that you want Single Sign-On, aka SSO. And I am talking about a real SSO, in other words, if you entered your credentials when you sign-in to your device in the morning, you should not be asked to re-enter them when you are accessing applications trusting your Azure AD during the day (so SSO with your Office 365 applications as well as other SaaS applications you might have signed up for). So SSO here means Single Sign-On. Not Same Sign-On (Same Sign-On is when you can use the same credentials to access your applications but it is not seamless, the user is prompted to re-enter them). Why do you need ADFS for SSO? Because you need your STS to be able to perform Windows Integrated Authentication. And long story short, your STS needs to be domain joined.

What am I losing if I am not using ADFS (or any other STS)?

It seems quite obvious if you read the previous section. You are losing SSO. So if you do not care about SSO, you could just use Azure AD and no federation STS at all (STS is Security Token Service, it is the generic term for ADFS, ADFS is the on-premises STS from Microsoft). But if we dig a bit deeper, there are some other reasons that might seem to you like corner cases but often turn out to be deal breakers for Azure AD and Office 365 projects.

  1. If you want to use Office 365, and you do not want to store your password in the cloud.
    First of all, when you are synchronizing your object in Azure AD with Azure AD Connect and you select the password synchronization feature, we do not store the password in the cloud. Then, in ADDS on-premises, we do not store your passwords either! We store the hash of your passwords. And when we synchronize passwords with Azure AD Connect, we hash the hash and store the hash of the hash in Azure AD. But still, if you do not want this, then you might consider not enabling the password sync feature and federate with ADFS.
    Update: Can do that with Azure AD Pass-through Authentication since this is now GA.
  2. If you want the authentication to take place on-premises.
    I have run into this situation a couple of times. You have a requirement to have all users authenticated on premises. Usually it is tied to the point above, the passwords need to be stored only on-premises. But I have also run into situations where the authentication process itself has to take place on premises. In that case you might consider federating your Azure AD with an ADFS farm.
  3. If you want to create a trust between SharePoint on-premises and Azure AD.
    You don't mind much about SSO, but there is this neat intranet on-premises running SharePoint that you'd like to federate with Azure AD. It is actually not possible to do as of today. SharePoint is expecting a SAML 1.1 token and Azure AD cannot issue this format of token. SharePoint isn't the only application in that case, in fact any application expecting a SAML 1.1 token cannot trust Azure AD directly. So here you might consider deploying an ADFS farm to do the transition.
    Update: Azure AD Premium can handle it: (thanks Steve!)
  4. If you need to send a very custom claim to your trusted application.
    If you need to transform an incoming claim into something that doesn't fit in what's available on the Azure AD portal, then you might need to use an ADFS farm to be able to craft the token the way you wish. I have seen customers with custom attribute stores in ADFS that they cannot reproduce in Azure AD.
    Update: New stuff available now: Customizing claims issued in the SAML token for enterprise applications in Azure Active Directory
  5. If you need to use your own MFA provider.
    Azure AD comes with Azure AD MFA. However, if you need to use another MFA provider than the Azure one (like one for your own on-premises security token solution), you might consider deploying an ADFS farm and deploying the custom MFA adapters on all the ADFS nodes.
    Update: About to change with the integration of a bunch of MFA vendors in the Conditional Access options.
  6. If you need to go beyond the Azure Conditional Access Policies you can choose from in the Azure AD portal.
    If you want to ensure legacy clients are not by-passing any of your policies, or you want to add some custom authorization rules that you cannot achieve with the Azure AD portal, then you might also consider deploying an ADFS farm.
    Update: The list of capabilities of Azure AD Conditional Access keeps growing. Although you cannot block legacy clients with Azure AD CA, you can force the legacy client to comply with MFA and not configure AppPassword. As a result, they won't be able to connect anymore.
  7. You need to use auto-registration for Windows 7 and 8.1 domain joined devices.
    This is to accommodate the "only domain joined machines can access Office 365" type of scenario for Windows 7 and Windows 8.1 domain joined. And this might require you to deploy an ADFS farm.
    Update: You can now use Azure AD Seamless SSO for this scenario, see: Update:
  8. Update: You want to avoid the Home Realm Discovery prompt with Azure AD Connect Seamless SSO. Despite the name, it is not so seamless. Well to be fair, you will be asked your email address when it is the first time you connect to your apps from your machine. Not too bad, but it seems that the only way to avoid this so far is to have a local STS supporting WS-Trust endpoint. 

I will miss you ADFS... Or the new feature that shrinks the list.

For points 1 and 2 there is a new feature to consider: Azure AD Pass-Through Authentication. So in a nutshell, you don't care about SSO. So you might consider the Azure AD Password sync. But you are in case 1 or 2. No passwords in the cloud or authentications have to be performed on-premises. This is what that looks like:

  • On-premises you have an agent (Microsoft AAD App Proxy Connector) constantly polling your Azure AD to check if there are credentials to check (it is important to note here that it is your agent contacting Azure AD and not Azure AD contacting your agent, so there are no incoming ports to open).
  • When the user typed its credentials, they are put in a queue in Azure AD and retrieved by the on-premises agent.
  • The agent verifies them and updates the queue with something like "good creds" or "bad creds".
  • Azure AD validates the authentication or prompts the user for its credentials again if they were incorrect.

So, great that we don't rely on ADFS to authenticate but still do not have SSO for your domain joined machines...

Wait a minute, why don't we do that the same way with domain joined machines and then we have SSO?

This is coming :) Update: It is here now. The preview feature is called Azure AD Connect Seamless SSO. The idea is that you would have SSO for your domain joined machines when they are connected on-premises. Like if you had an ADFS farm on-premises. Hum... To have a Kerberos type of SSO, the targeted services (identified by a SPN) have to be domain joined too. So the Azure AD "server" will be domain joined? Almost :) Will I have to open ports to my DC? No. In fact resources wanting to do Kerberos SSO do not need to be domain joined, but they need to exist as an entity holding a SPN in the forest and the resources need the cryptographic material to decrypt Kerberos tickets. You would have guessed, we create an account for that purpose in your ADDS (it is created by the AAD Connect wizard), with an SPN, we configure the user-agents (aka Internet browsers) to accept to perform Windows Integrated Authentication over the Internet but just for a specified Azure AD URL. And the magic takes place:

  • The user connects to an application trusting Azure AD from a domain joined machine.
  • The application redirects the user to Azure AD for authentication.
  • Azure AD (Update: Thanks to a JavaScript trick running in the background) responds with a HTTP 401.
  • The user then requests a Kerberos ticket for a specific SPN like it would do for any Windows Integrated Authentication.
  • The user sends the ticket to Azure AD.
  • Azure AD has the cryptographic material to decrypt it and to validate it.
  • SSO :)

So should I stop training or investing in ADFS?

Not at all! The list of scenarios where you need ADFS for Office 365 and Azure AD is getting smaller, but you can still use ADFS for other stuff than Office 365 and Azure AD. For example, you can use it for your own applications with no cloud involved. ADFS on Windows Server 2016 now supports all OAuth 2.0 profiles and OpenID Connect. So there are plenty of scenarios where it will do a great job federating applications.