Do I really need ADFS?


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

 

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 🙂 The preview feature is called Azure AD Connect 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 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 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.

Comments (12)

  1. Mike Crowley says:

    It seems WS 2016 wants you to setup ADFS through AAD Connect when federating with Office 365. Is it alright to ignore this and configure it manually with convert-msoldomain? I'd rather leave the ADFS environment independent from the AADConnect install.

    Also, is this cmdlet available in the replacement AAD module?

    1. You can configure both products separately. Those wizards (like the one suggesting installing ADFS from the AAD Connect page) are here to minimize the administrative overhead while deploying. Some think that it hides a complexity that does not appear obvious to them. You can go the way you want. If you know well about the two products, you can skip the wizard and do it the old-school way.
      I am not sure what your last question refers to? Which cmdLet?

      1. Mike Crowley says:

        Thanks for the speedy reply! the "old-school" way to setup federation with AAD for O365 is to use the convert-msoldomaintofederated cmdlet which automates the trust configuration on both Microsoft's and the on-premises end. That cmdlet is in the old "msol" cmdlet module which has been more or less replaced with the "azure ad" powershell module. I didn't see a similiar cmdlet in the new module, so I wasn't sure if this implied we weren't supposed to do it manually any more.

        1. Brian T. Grant says:

          Some of the naming conventions that MS can be a bit confusing but if you are referring to the Azure Active Directory Module that was last updated in August the "convert-msoldomaintofederated" is an available Cmdlet.
          Download page:
          http://connect.microsoft.com/site1164/Downloads/DownloadDetails.aspx?DownloadID=59185

  2. dave hood says:

    Thanks for the great post to help clear this stuff up. It seems to me that Ad Connect SSO really is a no brainer now. For many smaller customers ADFS was very off putting due to the server requirements. Do all the office 365 clients support it such as skype/outlook etc? I remember that some of the older outlook clients (2010?) poped up a login even if you had ADFS setup? Think that was solved with outlook 2013 with modern auth perhaps....

  3. 8. Support for SharePoint Online Auto Acceleration also need ADFS

  4. 9. Windows 10 auto registration with Azure AD only work with ADFS. Customers with seamless hybrid SSO doesn't get the device certificate from Azure AD, which is required for conditional access. https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/17439115-desktop-sso-hybrid-sso-support-for-joining-domai

  5. Jean-Yves Bonhomme says:

    Very good article Pierre. How can Microsoft make money with a licence-free product? 😀 at least, certificate expiration gives PFE easy missions

    1. I wish it would be certificate issues 🙂 Lately it is more advanced claim rules for conditional access, integration with SAML 2 claim providers, lockout tracking, custom attribute stores...

  6. James says:

    I'm running Azure AD Connect SSO and it's great, the only thing ADFS has over it from a UX perspective is ADFS can automatically use WIA, while AADCSSO still needs you to put in your UPN (or click on the saved one) before WIA is tried, even when a whr parameter is passed. Also it doesn't work in Safari or Mobile Safari (but does work fine in Firefox on Linux 🙂

    Personally I'm quite glad about not running ADFS, it's quite heavyweight given you need at least 4 servers for a proper deployment.

Skip to main content