Recommended audience: IT Operations Managers, Enterprise Architects, Solution Architects

This is a question that I have been asked often.

Do I still need Active Directory Federation Services (ADFS) to authenticate Office 365 users with my on-premises Active Directory?

The answer is: you might not need ADFS anymore!

Now we will explore why and how, but we must first analyze the common reasons that are given as a rationale for an on-premises ADFS deployment:

• Because it provides Single Sign-On (SSO) capabilities for my clients

• Because I need the sign-in process to be handled on-premises

• Because I need Multi-Factor Authentication (MFA)

Unfortunately, these statements do not justify the need to keep an on-premises ADFS infrastructure. Let’s first explore the decision flow to choose an authentication method for a hybrid deployment.

1. Do you want AAD to handle sign-in completely in the cloud? This question refers to the capability of Azure AD of handling sign-in without relying on on-premises components.

2. Do you want to integrate with an existing federation provider? Azure AD could handle sign-in to an external federation provider (e.g. ADFS).

3. Do you want to enforce user-level Active Directory security policies during sign-in? Active Directory security policies such as account expired, disabled account, password expired, account locked out, and sign-in hours on each user sign-in, Azure AD requires some on-premises components.

4. Do you have a sign-in requirement not natively supported by Azure AD? Currently AAD does not support the following authentication methods: sign-in using smartcards or certificates, sign-in using on-premises MFA Server, sign-in using third-party authentication solution, multi-site on-premises authentication solution.

5. Do you want sign-in disaster recovery or leaked credentials report? The user with leaked credentials report provided by Azure AD Identity Protection requires password-hash sync to be configured.

Only a limited number of cases require ADFS

If we analyze the decision flow, we can conclude that only a limited number of cases require to have ADFS. Only when there is an unsupported authentication method or complex claim rules that cannot be migrated to Azure AD. Even if usually an application just requires the user identifier and the application roles for RBAC permission determination.

The initial answers to the question “Do you still need ADFS?” can now be analyzed through the decision flow.

• Single Sign-On is not part of the decision criteria because it is compatible with both Password hash-sync (PHS) and Pass-Through Authentication(PTA) methods supported by Azure AD.

• The on-premises authentication requirement can be handled with Pass-Through Authentication (PTA).

• Multi-Factor Authentication (MFA) can be managed also by AAD in the cloud with Microsoft as the authentication provider or a third-party MFA provider (upcoming capability as of May 2020)

For the vast majority of ADFS deployments, Azure AD could handle all requirements.

What are the benefits of migrating your application authentication to Azure AD?

Risk management

• Secure access to applications and associated data using Conditional Access policies, MFA and Identity Protection technologies, leveraging Azure AD as the single point of application access control.

• Rely on Azure AD high-available and distributed design.

• Integrate your existing applications with a secure hybrid integration from a partner that you might already be working with within your application ecosystem, including access to on-premises applications with Azure AD Application Proxy.

• Have a single set of application access and control policies across cloud and on-premises environments, to increase application security.

Cost management

• You might be paying already for Azure AD licenses through a purchased subscription such as Microsoft 365, therefore if you are using multiple Identity & Access Management (IAM) solutions, you can consolidate them into one, with Azure AD.

• Eliminate the ADFS infrastructure and associated costs: server’s maintenance, certificates, load balancer and SQL Server High-Availability (HA), plus the operational costs of troubleshooting complex issues that require specific skillsets.

Productivity management

• Improve the end-user experience by implementing Single Sign-On to access applications from any device, whether it is corporate or not.

• Leverage self-service IAM capabilities, like Self-Service Password Reset (SSPR), Self-Service Group Management, and dynamic group membership.

• Use a single identity across all cloud applications using automated provisioning of user identities.

• Collaborate securely with partners using Azure B2B collaboration, with or without direct organization federation, and automate the users’ lifecycle with Identity Governance.

Now that we’ve analyzed the benefits of transitioning applications to Azure AD, let’s see how to do it.

What are the steps to migrate from ADFS to Azure AD?

The migration steps can be broken down into three major phases.

Observe

Chart

 

Plan apps migration and users’ transition.

Plan communication changes to the end-users.

 

Launch

 

 

Let’s explore in detail each phase.

Observe

In this step you should identify the applications that must be deprecated; hence they will not be migrated to Azure AD authentication, and applications that will be in scope for migration. For the latter, automated discovery can be used to help you in the discovery process, with these approaches:

• If you have Azure AD Premium you can use Azure AD Connect Health reporting features to analyze apps’ usage.

• Use ADFS application activity reporting (in preview as of May 2020) to analyze applications in ADFS and evaluate readiness for migration with analysis against pre-configured rulesets.

• Another approach without AAD premium licenses is to use ADFS log parsing using the ADFS Toolbox PowerShell modules.

After the discovery phase, you will have a list of applications that you need to sort by criticality, usage, lifespan, and readiness. With the outcome of the observe phase you should: match the applications’ discovery report with a list of systems each application connects to; identify the users’ locations; identify the users’ devices; identify the business owners of the applications.

Even though the automated processes will give you a good overview of all applications used in your organization it’s better to complement this list with a manual process to ensure that the list is as comprehensive as possible.

Now that we have a comprehensive list of applications let’s move on the following phase.

Chart

The output of the previous phase will serve as input for this one, which aims at planning the detailed migration steps of apps and users, including the communication and instructions to be sent to them on how to access the migrated applications via the applications access panel.

After the applications’ discovery phase, you can have two types of applications to migrate:

• Applications using modern authentication protocols (such as SAML or Open ID Connect) can be reconfigured to authenticate with Azure AD either via application registration, (including Line-Of-Business apps, developed in-house and supporting modern authentication protocols), or by using a built-in connector from the App Gallery (for SaaS applications such as Salesforce or ServiceNow).

• Applications using legacy protocols (IWA, Integrated Windows Authentication, form-based, header-based access) can be migrated using Azure AD Application Proxy, which provides also the capability of making these applications available while maintaining them in your on-premise environment. I will cover Application Proxy in a different article.

After the configuration of applications in Azure AD and the mapping of all settings, the next step is to prepare users and groups for the transition. The following elements must be considered:

• Synchronize to Azure AD all users and groups that have permissions for the applications that are in the scope for migration.

• Ensure user identities and groups are provisioned in the applications. You can take advantage of Azure AD automatic provisioning capabilities (via SCIM protocol configuration or via a configuration page for pre-integrated apps in the gallery), or alternatively provision manually the identities in the applications’ configuration pages.

• Enable external users to access the applications you migrated: if the external users exist as internal accounts within your organization, consider migrating them to Azure B2B collaboration to streamline the login process since you won’t have to maintain anymore those accounts and they can use also their own corporate credentials to access resources you make available. The workflow of adding external users can be managed via the Azure Portal or you can customize the experience via the Azure B2B invitation API.

• Another capability currently in the preview stage is to add your SAML or WS-Fed ADFS trusts with external organizations using Azure B2B direct federation, which allows your organization to trust an external one without the invited users having to redeem the invitation, instead, they will be automatically logged in using their corporate credentials.

I will cover the Azure B2B collaboration capabilities in a separate article, also combining the concepts of managing the external users’ permissions and lifecycle with Azure Identity Governance and securing the external accesses.

Identified Limitations

The following configurations cannot be migrated today and must be reanalyzed to migrate them using an alternative approach:

• WS-Trust ActAs pattern.

• SAML artifact resolution.

• Signature verification of signed SAML requests: Azure AD accepts signed requests, but the signature is not verified since Azure AD will return tokens only to authorized and configured endpoints per each application, this is less likely to be required.

Now that we took care of all the planning aspects it’s time to execute the migration.

Launch

Now that we are ready to migrate users and applications, the following steps can be applied in sequence to ensure that the migration is successful and tested before rolling it out to production:

• Perform the steps described in the Chart phase to migrate the apps and users to Azure AD, leave the federation with ADFS in place if you need to rollback or until the application migration is fully tested.

• Review your conditional access policies for each application or group of applications and the SAML/WS-Fed configuration to ensure it is correct.

• Ensure that your SAML settings are correct by using the Test SAML Settings function in the SAML configuration.

• Communicate to the end-users how to access the applications and ensure support for any request.

• Instruct users how to verify or update their MFA and Self-Service Password Reset settings (if activated).

• Ensure that external partners are aware of the migration schedule and are involved early in the pilot phase to discover and report back any issue.

You don’t need to perform a cut-over in a single-staged big bang approach, but you can migrate to cloud authentication by using Azure AD staged rollout. This will allow you to run in parallel the federated authentication and the chosen cloud authentication method (whether Pass-Through Authentication or Password-Hash), whilst retaining control of which user group will be enabled for one authentication method or the other. This feature also includes the possibility to test Seamless SSO to provide Single Sign-On capabilities to your domain-joined computers if Azure AD Join is not used in your environment.

How can we help you?

At Stellium, we have supported many companies in the implementation of federated and cloud authentication methods, and we can help you to analyze your current situation and migration steps to move forward with modern cloud authentication.

Would you like to get in touch about ADFS assessment and migration? Go ahead and set up an appointment for a consultation call