Microsoft’s Active Directory Federation Services (AD FS) was, until recently, the company’s sole option for customers that wanted single sign-on (SSO). However, it’s not a rudimentary setup and takes considerable time and effort to manage. There are now multiple alternatives, including JumpCloud’s SSO. This article outlines two migration paths to help you move on from AD FS and also provides an overview of what’s involved with a complete migration from Microsoft.
First, let’s explore the benefits of moving on from AD FS to more streamlined SSO services.
Why Migrate from AD FS?
Simply put, most small to medium-sized enterprises (SMEs) just don’t need AD FS.
Microsoft’s own words are the most blistering indictment of AD FS:
“We do not recommend this option unless you need federated single sign-on and on-premise password management. This path is more difficult and expensive, requires the management of multiple servers, and is only relevant for districts with complex security set-up and requirements,” it wrote in guidance for customers in education.
Part of this complexity arises from its utilization of security token services, obligating its users to deploy and maintain a server farm that even Microsoft says is, “complex and expensive.” Multiple servers, integrations, and advanced network settings are required to deliver real SSO.
The TL:DR on this writer’s adventure with AD FS, installing Active Directory Domain Services (AD DS) and AD FS, a web application proxy server role on another server, and then configuring an external domain for authentication: hours spent waiting for each instance of Windows Server to patch and update.
Microsoft’s latest options are Azure AD SSO or Intune, which require multiple subscriptions per device. If you’re unsure which subscriptions are required, you’re not alone; many IT admins struggle to navigate them. Its other Azure services aren’t SSO and leave the OS as its own silo, complicating user management and layering on complexity and maintenance costs.
Microsoft gave Active Directory away for free, but its mobile device management (MDM) services will cost you and aren’t fully cross-OS. Microsoft’s present vision for domainless enterprise essentially means: “you will pay more for each user; don’t use Linux.”
Migrating to JumpCloud
Migrating from any established system is a commitment in time and resources; when approaching a project like this, it’s essential to calculate the future cost savings (also in time and resources) to effectively justify the project and garner buy-in. JumpCloud provides far lower management overhead with additional capabilities that AD FS doesn’t. It’s also truly cross-OS, and extends into device and user lifecycle management. JumpCloud has significantly less attack surface area, which can intrinsically improve your cybersecurity.
JumpCloud is cross-OS and provides a core set of identity and access management (IAM)
features without charging you extra and with the capacity to securely connect to and manage more things (RADIUS, SSO, MDM, MFA). You can do much of what you already do on your domain controller, but have deeper device and patch management options. You can also patch your systems and implement additional Zero Trust security controls such as premium conditional access policies and integrated attribute-based group membership.
The platform keeps track of which identities have access to what resources, and makes suggestions when permissions violate the concept of least privilege. JumpCloud is the modern alternative to AD FS that enables you to access what you want, anywhere you want with far less effort. JumpCloud doesn’t require a boatload of add-ons to accomplish what you want.
Preferred Method: Syncing AD User Identities with SAML
The “cleanest” migration path from AD FS is to sync your user identities from a web directory such as Azure Active Directory (AAD), Microsoft 365 (M365), or Google Workspace. JumpCloud’s SSO connectors will import users and most common user attributes via SAML, an open standard for SSO and authorization. This step is a prerequisite for this approach, so please move on to the next section on Active Directory Integration (ADI) if you’re not using AAD, M365, or Google. JumpCloud provides the following detailed user provisioning guides for those services:
You’re now ready to migrate your SSO from AD FS to JumpCloud. There are upfront steps to prepare for: reconfiguring your services for JumpCloud SSO and user awareness and training. JumpCloud has made this step easier with its connector library. You may also create custom SAML integrations, but keep in mind that SAML settings are “all or nothing.” Please fully test your integrations prior to making the switchover to avoid disruptions to your user workflows. Your users will access their apps through the JumpCloud user portal.
User access can be granted for apps by importing or creating new group memberships. This approach has the benefit of making user onboarding or offboarding more consistent and secure.
Cross-domain Identity Management (SCIM) is another integration option. It’s possible to use JumpCloud’s SCIM server to manage your organization’s user identities in Azure AD, and easily connect users to all of the IT resources they need through JumpCloud. Updates are injected into JumpCloud via SCIM. This SCIM KB article “Generically Integrating Azure AD with the JumpCloud SCIM Server” outlines this process in great detail.
- From the Provisioning dashboard, click Provision on demand, search for the user that needs to be added, select them, and click Provision. This will push the new user to JumpCloud immediately.
- The user is added in a Password Pending status. Azure AD doesn’t pass the user’s password to JumpCloud. You’ll be able to manage the attributes, users, and activation_state (disable/active).
- If changes are made to this user within JumpCloud, it won’t be reflected in Azure AD through this integration.
- Groups will have to be independently managed between JumpCloud and Azure AD.
Two Options: Keep Active Directory or Move to JumpCloud
You may now skip ahead to the decommissioning AD FS section for instructions on how to “clean up” and then re-provision or repurpose your Microsoft servers. Please note that there’s a difference between no longer using AD FS for SSO and migrating away from Active Directory itself. JumpCloud can coexist with AD for scenarios such as when you’re running a file server, Exchange, or SharePoint on premises.
Removing AD FS won’t “break” your infrastructure, but your SSO configuration will change. Otherwise, users who don’t have those dependencies will have the option to ditch their domain controller for the domainless enterprise.
- Optional: Roadmap to the domainless enterprise
- Converting Windows System Active Directory Domain Accounts to Local User Accounts
Alternative: Active Directory Integration (ADI)
You’ll be required to set up ADI in order to migrate AD identities from AD DS to JumpCloud. Please note that we do not recommend AD Integration as the means to import users, unless it will be used moving forward to keep identities in sync. This method begins by integrating Active Directory Domain Services with JumpCloud, without any intermediary cloud services. Users that have set up M365 or AAD shouldn’t follow this migration path.
The initial step is to have permission to install the JumpCloud agent on your domain controller. Then, you have two options: keep Active Directory as your IdP to authorize and manage users, or extend your directory to JumpCloud, allowing the JumpCloud platform to handle SSO.
- AD Sync is used for user provisioning and SSO. It enables you to maintain your directory within AD DS and to sync with JumpCloud. JumpCloud will be your IdP (SAML SSO). It provides a one-way synchronization of passwords and attributes from JumpCloud to Active Directory. In this case, you will no longer be managing your users from AD. For example, if you make a password change to a user in JumpCloud it will sync to AD. This method of integration between Active Directory and your domain controller can be used to establish SSO for device logins as well as external web app access control. JumpCloud’s multi-factor authentication (MFA) can then be configured to protect your accounts.
- AD Import works in the opposite direction from AD FS to JumpCloud, maintaining AD as your default directory. MFA is important for security, and you’ll need two systems in this instance (assuming you have one on premises). One is the MFA provider that’s configured on your domain controller for local authentication before the firewall; you’ll use JumpCloud MFA for (SAML) SSO authentication over the WAN.
- Use both utilities if you want full bidirectional synchronization.
ADI is less optimal than SAML (outlined above) for full migrations to JumpCloud away from both AD DS and AD FS. This is because settings such as attributes aren’t transferred as easily as if you were to use an SSO connector to integrate JumpCloud with AAS, M365, or Google.
JumpCloud replaces AD FS for SSO, eliminating the need for an SSO server farm
Decommissioning AD FS
AD FS has a very complex architecture, per Microsoft. There are a number of changes that must be made to decommission it as your SSO infrastructure that have varied security and IT management implications. Please do not skip this step or delay the decommissioning process.
- Remove any AD FS related settings from your load balancers (internal and external)
- Delete all responding DNS entries related to your AD FS environment
Remove Relying Party Trusts
Relying party trusts were set up on the server running the AD FS role to configure service providers to run with AD FS as the IdP, behind your firewall. These should be cleaned up from the AD FS management tool that’s found in Server Management in Windows as you transition services.
- Go to the Relying Trust Party folder
- Expand the list of relying party trusts, right-click Cloud Identity, and delete the entry. You may be asked to verify the deletion.
Example of a relying party trust configuration for Google accounts (credit: Google)
There are support articles that outline how to conduct this step using PowerShell.
Recommissioning or Repurposing AD FS Related Servers
The depth of this step will depend on whether you’re:
- Keeping AD FS and removing the AD FS role; or,
- Fully decommissioning Active Directory
Let’s begin by uninstalling the web application proxy (WAP) server role(s), followed by AD FS. These will be hosted on two separate servers.
- Remove WAP by locating published web applications related to AD FS under the Remote Access Management Console and deleting them. Then, remove the WAP feature at the PowerShell interface with the following command:
It may take a while, but the following dialog means it’s working:
The output will match this if you’re successful:
Removing the AD FS Server Role
First, run this command before you do anything else.
- (Get-ADFSProperties) to find the CertificateSharingContainer
- Be sure to record the location of this container
Photo credit: Microsoft
Begin the process of removing the AD FS server role (on each node) with the following PowerShell command with elevated user permissions:
Then, be sure to delete the artifact folder and associated database.
Lastly, there’s one final step required, because Microsoft’s uninstall process fails to delete the certificate sharing container that AD FS created within AD DS.
- Launch the ADSI Edit tool to manually remove the content of CertificateSharingContainer from your Active Directory forest post uninstallation. Several reboots may be required.
- Then, delete any AD FS service account from AD DS. Recall that you were asked to create a dedicated service account for your server farm during its setup. It’s important not to leave any “forgotten” privileged accounts running within your AD domain.
- You now have a Windows Server that can be repurposed for another reason, but from an information security standpoint it’s often better to start from a clean install.
Decommissioning a Domain Controller
This step only applies to users who are replacing Active Directory with JumpCloud. The work that’s involved varies depending on the complexity of your environment. Please refer to this article for the four basic steps needed to complete the migration. You’ll ultimately migrate every domain-bound Windows system from AD to JumpCloud, but JumpCloud can also coexist with Active Directory until you’re ready. New JumpCloud users receive 10 days of complimentary support. JumpCloud’s professional services are available for more complex engagements, or work with an MSP partner to assist you with your project. This video outlines the migration.
Tip: Remember to contact your MSP partner or Microsoft reseller to renegotiate your Client Access License (CAL) or Software Assurance volume licensing to reclaim your AD FS budget.
AD Migration Utility (ADMU)
The JumpCloud Solutions Architecture team has built an open source tool, AD Migration Utility (ADMU), to streamline the process for new JumpCloud users who are working independently on these migrations. It is designed to streamline the transfer of Active Directory or Azure Active Directory accounts to local accounts for subsequent JumpCloud takeover and management.
Backups and Continuity Planning
Be mindful that domain controller and other server backups can become a security risk if they’re unencrypted. Destroy your backups once it’s appropriate to do so, or downgrade cloud backup plans to reduce overall IT spend. Also, remember to revise your business continuity plan with an assessment of your JumpCloud cloud infrastructure and how your risks have changed.
Try JumpCloud for SSO and More
The JumpCloud Directory Platform connects you to more things and is free for 10 devices and 10 users with complimentary premium chat support. Support is available 24x7x365 within the first 10 days of your account’s creation to assist with your migration away from AD FS. JumpCloud’s community is another resource to ask questions and collaborate with your peers.