Do I really need ADFS?

Articolo
02/06/2017

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.

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.
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.
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: https://docs.microsoft.com/en-us/office365/enterprise/using-azure-ad-for-sharepoint-server-authentication (thanks Steve!)
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 https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-saml-claims-customization
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.
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.
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: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso
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.

Comments

Anonymous
February 07, 2017
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?
- Anonymous
  February 07, 2017
  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?
  - Anonymous
    February 07, 2017
    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.
    - Anonymous
      February 09, 2017
      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
    - Anonymous
      February 09, 2017
      This is an available Cmdlet.It can be downloaded:http://connect.microsoft.com/site1164/Downloads/DownloadDetails.aspx?DownloadID=59185
Anonymous
February 08, 2017
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....
Anonymous
February 09, 2017

Support for SharePoint Online Auto Acceleration also need ADFS

Anonymous
February 09, 2017

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

Anonymous
February 10, 2017
Very good article Pierre. How can Microsoft make money with a licence-free product? ? at least, certificate expiration gives PFE easy missions
- Anonymous
  February 10, 2017
  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...
Anonymous
February 11, 2017
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.
- Anonymous
  April 26, 2018
  Yeah this can get annoying, especially if your intranet page is SharePoint Online. You have to continually 'select your UPN' any time you visit the page and you can no longer select 'remember me' option. Not sure if there is a way around this with Seamless SSO and not using ADFS?
Anonymous
June 13, 2017
Great post, thanks.
Anonymous
September 01, 2017
When deciding between the 2 technologies - If you will be using Conditional Access in Azure, and have applications that do not use modern authentication (Office 2010), you will have to use AFDS to apply conditional access for these clients.
Anonymous
September 29, 2017
Nice post, thanks Pierre. I often get asked "why don't we just sign on via AAD", this summarised why we still need ADFS very well.
Anonymous
January 24, 2018
Great article!Very well written.
Anonymous
February 21, 2018
I wanted to add few more Advantages of ADFS8. To create Trust between two different domains 9.To Implement an SharePoint application/Any Application with Cross authenticate between two different domains
- Anonymous
  February 26, 2018
  Indeed. The article focusses on why we would still need ADFS in an Office 365 / Azure AD trust scenario.
Anonymous
March 23, 2018
#8: As of 3/23/2018, ADFS is the only way to block legacy authentication. https://docs.microsoft.com/en-us/azure/active-directory/active-directory-conditional-access-no-modern-authentication#set-up-ad-fs-rules. So if you want to block legacy authN, you need ADFS.
- Anonymous
  April 04, 2018
  Yep. Although one could argue that if you force MFA for everyone, and don't have the App password (pre-enroll users and don't tell them the password for example), it will effectively prevent them from using legacy clients.Now, some new options in Azure AD CA will be released soon that will address this gap.
  - Anonymous
    April 11, 2018
    Misleading statement, if you 'enforce' MFA on the phonefactor portal on every account in AAD, you can block legacy authentication. If you use conditional access, you are still 'open' to legacy auth.
    - Anonymous
      April 12, 2018
      Very true! Good catch! You block the client access, the authentication still does work. The point here being that the access to emails will effectively be blocked if MFA is enforced.
Anonymous
April 10, 2018
Re point 3... you can now issue SAML 1.1 from Azure AD:https://docs.microsoft.com/en-us/office365/enterprise/using-azure-ad-for-sharepoint-server-authentication(Azure AD Premium required)
- Anonymous
  April 10, 2018
  Thanks for pointing that out! I will be adding it shorty!
Anonymous
May 25, 2018
Thanks for sharing and keeping the post updated. There are still requirements where a "classic" ADFS implementation is required due to internal network connection limitations.
Anonymous
August 15, 2018
excellent article, but the section "What am I losing if I am not using ADFS (or any other STS)?" is worded awkwardly, with the if statements below, as they end up reading "What am I losing if I am not using ADFS (or any other STS)? [...] If you want to use Office 365, and you do not want to store your password in the cloud." See? it makes no sense
- Anonymous
  August 19, 2018
  Hi Greg! Thanks for the feedback. The titles of each section are just here to attract attention. All my posts are written in a very casual tone. Can you suggest a better way to phrase it? Thanks!
Anonymous
October 26, 2018
Questions: We are implementing ADFS with O365 and sync passwords to Azure AD. A user is using a domain joined machine, the machine in currently connected to the domain, and use Skype (or another O365 app). What is the path of authentication? Azure AD (user exist?) -> ADFS (SSO) -> on-prem AD (?) -> O365 (check license)? What happens if the same user is at home on a web browser? Does the path go back to internal ADFS and AD to check on user or straight to AAD and O365?
Anonymous
February 28, 2019
My company is feeling abandoned by another expensive Microsoft Server based technology that took a ton of time, energy and money to install.
- Anonymous
  March 27, 2019
  Why abandoned? ADFS is still around, it is just not a requirement to achieve SSO with Azure AD.

Condividi tramite