As a professional, I like to prepare my projects to avoid any hick-ups during stressful moments. From reading up on the relevant Microsoft Docs, implementing a staging environment to define run and rollback changes to triple-checking my assumptions.
Recently, I have been involved in several projects for decommissioning Active Directory Federation Services (AD FS). Staged roll-out is a feature that helps migrating the user population from AD FS to managed authentication granularly. Other federated applications, services and platforms don't offer this kind of functionality and require the entire population be changed from authenticating to AD FS to authenticating to Entra. This cutover moment can be stressful. A lot of things can go wrong. Therefore, I'm sharing three gotchas when migrating applications from AD FS to Entra.
1. Applications may use a federated protocol that is not available in Entra
Some AD FS implementations have a lot of applications, and sometimes these applications use legacy protocols. It's not a problem when an application uses WS-Fed, SAML 1.0, or SAML 1.1 anymore, as these legacy protocols and versions are all supported by Entra. However, one particular federation protocol was never implemented in Entra: Shibboleth. This protocol was – and still is – primarily used for multilateral federation between universities and research facilities.
Microsoft offers three solutions for organizations:
- Microsoft Entra ID with Cirrus Bridge
- Microsoft Entra ID with Shibboleth as a SAML proxy
- Microsoft Entra ID with AD FS and Shibboleth
All these solutions respect Shibboleth as the federation protocol in use, but also all result in the AD FS implementation or other on-premises functionality is maintained. Mostly, the purpose of an AD FS migration project is to decommission on-premises functionality… Therefore, migrating to Entra External ID may be the best long-term solution, but this is going to take some time to architect, implement and perfect… while AD FS keeps running all the while…
2. Applications may use an outdated attribute for Name ID
When you've been working with Entra, you've become very familiar with the userPrincipalName attribute as the sign-in account towards most Entra-connected applications, services and platforms. When the primary user email address and userPrincipalName attributes match, people in your organization only need to remember one sign-in name.
However, in the early days of AD FS, the userPrincipalName wasn't as widely used as the globally unique user name it is considered to be today. In older Active Directory environments, it's even possible to spot accounts with empty userPrincipalName attributes. These environments rely on other attributes. The sAMAccountName attribute is typically used in these environments. Yes, in the Active Directory tooling, this attribute is referred to as the pre-Windows 2000 user name…
These outdated configurations in AD FS may prove cumbersome during the migration from AD FS to Entra, as the default application settings for multi-tenant applications configure the userPrincipalName as the sign-in attribute.
From a user perspective, nothing seems wrong, as AD FS performs its single sign-on magic with Active Directory in the same way. However, in the back-end of the AD FS-integrated application, service or platform, records for user accounts would have settings, profiles, permissions and history linked to a user table with sAMAccountName values. Oftentimes, the sAMAccountName attribute is then appended with the organization's public DNS domain name.
When not addressing this issue, switching the Name ID attribute from sAMAccountName (in Entra user.onpremisessamaccountname) to userPrincipalName (in Entra: user.userprincipalname) through these default settings would create all new users in the back-end, typically without the right settings, permissions, etc.
To avoid this, the back-end of the AD FS-integrated application should be converted from using the sAMAccountName attribute as the Name ID to using the userPrincipalName attribute. Depending on the vendor and contracts, this could easily add months to your AD FS migration project…
Avoid this situation by going through the claims issuance rules of AD FS-integrated applications, services and platforms and make sure these don't issue the sAMAccountName as the Name ID.
3. User assignment does not support group nesting
In Entra, it is a recommended practice to toggle the User assignment required setting for enterprise applications to Yes. This ensures that only people with user accounts that are members of a specific group have access to the functionality by configuring specific groups to have access.
However, the User assignment required setting and the groups that are added cannot be nested groups. In AD FS, group nesting was never a problem in claims issuance rules, so group nesting may suddenly become an issue when migrating an application, service and/or platform from AD FS to Entra.
The only thing that can be done is flattening the group memberships by adding the specific members of a sub group to the primary group. This takes time, so it's inconvenient to be confronted with during the actual application migration. Address this issue before migrating the application, service or platform from AD FS to Entra.
Login