Migrating your Active Directory Federation Services (AD FS) integrated SaaS applications to Entra ID (formerly Azure Active Directory) provides many benefits. For example, Entra ID B2B lets you give your business partners and customers access to your organization’s applications without creating a user account in AD or Entra ID. Conditional Access is another useful Entra ID feature that allows you to enable controls such as multi-factor authentication or block access due to risky sign-in behaviors by authenticating users. Once you migrate all your integrated SaaS applications to Entra ID, you can completely deprovision your AD FS deployment.
We’ve encountered several issues when migrating customer implementations from AD FS to Entra ID. The following advice will help you avoid the problems we’ve faced.
Plan Your Migration Based on SaaS Application Usage, Impact, and Complexity
Not all SaaS applications will migrate from AD FS to Entra ID smoothly or quickly. Entra ID has a Usage & insights report for AD FS application activity that you can use to determine the overall usage of an application. This report is populated through the Entra ID Connect Health for AD FS agent, which must be installed and registered on each AD FS server and Web Application Proxy server; in addition, you must enable auditing for AD FS.
Once installed, registered, and enabled, the report will begin to populate with usage data. You should have a reasonable view into the application usage after 2 weeks. Be sure to allow enough time for your users to operate normally; for example, a holiday week when half your users are out of the office isn’t an ideal week to monitor. Each application that has been accessed will be listed in the report, along with the unique user count and a column indicating migration status.
The Migration Status column is useful because some of the manual effort of evaluating applications’ configuration complexities is done for you. If an application has a status of Ready to migrate, you shouldn’t experience any complications in migrating the application to Entra ID. If the status is Needs review, you’ll need to manually review the AD FS configuration to determine its complexities. The application can be migrated, but you may need to alter some settings first. Lastly, if the status is Additional steps required, the application cannot be migrated because at least one application setting isn’t supported by Entra ID.
The Usage & insights report allows you to create a prioritized list of applications that are in use based on their utilization by users, as well as on the initial evaluation of application settings. However, the report doesn’t provide details on the impact of an application to your organization. You must determine the impact based on the specific application and its use. For example, a payroll application or VPN access may be considered critical compared to a collaborative chat platform.
You should consider all three factors—usage, impact, and complexity—to prioritize applications for migration. An application with the most usage but a status of Additional steps required may take substantial effort to migrate, if it can be migrated at all. Applications with a status of Ready to migrate are very simple to move.
Avoid Getting Locked Out of the SaaS Application
Some SaaS applications allow end users to administer their SSO configurations without requiring the vendor to assist. In these cases, we recommend that you set up a test instance and have a method to authenticate as an administrator natively within the application to prevent loss of access. The test instance will allow you to test the migration without impacting users who may be using the application already. If the metadata within the application is entered incorrectly or a claim rule isn’t accurately replicated from AD FS, you may find yourself with no way to access the application to make configuration changes.
Many vendors have a direct authentication option using a custom URL that bypasses SSO and allows for a legacy authentication option using a username and password. This may require a special administrative account because your existing SSO-enabled account may not be usable in this way. If the vendor doesn’t have an option for direct authentication once SSO is enabled, it’s highly advisable to ask the vendor what options they have for this backup access.
Be Aware of Custom Claim Rules
Although Entra ID has substantial support for unique claim rules, including transformations and static values, some applications that are integrated with AD FS use methods that aren’t available elsewhere. A few limitations exist that could prevent an app from being migrated. For example, not all Entra ID attributes are available from on-premises AD. In many cases, options such as custom sync rules or extension attributes are available if the attribute to be used isn’t part of the standard user schema in Entra ID.
If you can’t replicate custom claim rules in Entra ID, you may need to evaluate them. Often a complex claim rule in AD FS exists because of legacy configurations and limits that existed at the time of creation. In addition, the SaaS application vendor may have updated its configuration requirements to support Entra ID. As Entra ID has matured, options are available to match most AD FS claim rules. However, a few claim rules still aren’t supported by Entra ID.
Watch for Identifiers That Don’t Match the Cloud UPN
The NameID claim in AD FS allows for additional unique configuration options that may not be supported in Entra ID. You may find that the claim rule in AD FS isn’t as simple as just sending an attribute as-is but may involve translations, substitutions, or static values. This may require you to modify the application’s configuration or the claims being used to support the application needs.
Older custom configurations may be based on the SaaS application vendor’s guidance at a time when Entra ID wasn’t as widely adopted or as supported as it is now. The SaaS application vendor may have updated guidance on the configuration requirements to support Entra ID. The vendor may also allow reconfiguration of its application to support a standard claim vs. using NameID as the identifying claim. Because Microsoft adheres to SAML 2.0 specifications, NameID has limitations compared to standard claims. Many vendors do not adhere to SAML 2.0 specifications and therefore the NameID claim configurations they ask for aren’t possible.
Plan Ahead to Ensure Success
Vendor support is the biggest complication or delay with these types of migrations. Many SaaS applications require the vendor to assist with SAML configurations. The vendor’s availability often causes delays in migration projects. In addition, some vendors charge a fee to implement any changes.
An AD FS to Entra ID migration project, whether it includes 5 or 150 SaaS applications, requires adequate planning and an understanding of SAML authentication to successfully execute. If you need help with planning a project to ensure its success, contact the experts at Ravenswood Technology.
