Time to get rid of ADFS

Executive summary: There is little to none reasons still using ADFS for Office 365 logins. Azure AD Premium Plan 1 licensed organizations have little to none reasons still using ADFS for anything. Migrate. Now.

Previously I have been installing high available ADFS farms to almost every customer that had more than few users and wanted single sign on to Office 365. Today, Microsoft has good documentation how to choose authentication for your use. 95% of use cases end up something other than ADFS. My recommendation is always use Password Hash Sync and incorporate it with Pass-through Authentication if strict enforcement of local AD policies is needed. Doing this enables more identity protection features f.ex. stolen passwords could be detected.

What about all the other federations for SaaS applications?

In most of the customer cases I have worked in, ADFS was built because of Office 365 and then more applications got added to it. Using one common identity and authentication source increases security as a user account is more probably closed when employment ends. It will also increase end user satisfaction as they don’t need to remember multiple user names and passwords and will login to all applications automatically.

In most cases you could move those applications to use Azure AD as their authentication source. Creating a new SaaS application that authenticates using SAML needs an Azure AD Premium P1 license. Actual application registration takes no more than two minutes if you have all the details available.

From Azure AD management portal, click Enterprise Applications -> Add an Application -> Non-gallery application and give it a name. The name is displayed in My Apps portal so choose wisely.

If this application is used by everyone in your organization, go to the properties of the newly created application and change “User assignment required” to No. Otherwise you must assign the application to an individual user or group.

Then, in Single sign-on tab, choose to use SAML and you end up with this kind of settings:

Only mandatory settings are Application Identifier and Reply URL. These are something that you find from existing ADFS federation. If there are no special claims used, that’s it. Just save, deliver metadata URL to SaaS provider and enjoy the magic. In this demo I use ADFS Help as application. ADFS Help is a very neat service from Microsoft for debugging all kinds of federated logins etc. In this case, I get a full list of claims provided by federation. This could also be used in complex scenarios for debugging issuing rules.

What are the benefits of doing this?

Single Sign-on from any device that is joined to Azure AD. This also applies to mobile devices if they are Azure AD joined. You can get some of the benefits also by using Seamless SSO, but join devices to Azure AD to get all the joy out of this.

Single point of application access and control. You can use Azure AD not only to define who can access which Office 365 application but also to specify what 3rd party SaaS applications end user can access. End user will have My Apps portal for all the applications they have access to.

Conditional Access polices can also be defined to secure 3rd party SaaS applications. This is something really useful. You can specify that for example Salesforce is usable from trusted devices without any additional authentication but using it from un-managed devices requires multi factor authentication. Read more about Conditional Access from Matti’s post.

Enable users to self change and/or reset their passwords. You can use built-in Azure AD functionality to enable end users to change or reset their passwords. This requires enabling password writeback to the onprem AD.

You can get rid of all the ADFS servers and infrastructure. This might be four servers and load balancer. Azure AD Connect and Pass-through Authentication agents can co-locate with some other servers. Best practice however suggests that servers hosting these services should be treated as tier 0 servers.

Are there any caveats?

There are some limitations if not using onprem ADFS that you need to understand. For example you could not use certificates for logging in to services. Get familiar with Microsoft documentation about choosing the authentication method: https://docs.microsoft.com/en-gb/azure/security/azure-ad-choose-authn.

If you have been using Custom Attribute Store, for example SQL, in ADFS, that is something you don’t have in Azure AD. If your solution requires this, you must use ADFS.

Transformation rules of claims are still better and support more compex transformation in ADFS than Azure AD. If you need to transform claims or create federation chains, ADFS is the way to go.

Some of the claims are restricted and you could not use Azure AD to send those. If those are needed, ADFS must be used. In many cases this could be overcome using transformation rules in relaying party end. The list of restricted claims is available here.

What about sending group memberships?

I have often heard that you could not send partial set of user’s groups as claims if using Azure AD. This is partially true. You can not customize claim issuance rule to filter memberOf groups based on attribute or other group as you might be doing in ADFS. However, this can be solved in most cases by mapping groups to roles and sending those roles out as claims. In most cases that is actually what is needed. Just add user.assignedroles attribute for issued claims list using the claim name that you need.

Creating new custom roles could be tricky, but it can be accomplished by manipulating the manifest of the application. Read more from: https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-add-app-roles-in-azure-ad-apps