Video Transcript:
-Did you know you can migrate off Active Directory Federation Services without anyone feeling it? Today, I’ll dive into Active Directory Federation Services and everything you need to know about migrating what you have running now to Microsoft Entra ID, or what used to be called, Azure Active Directory. And if you’ve been blocked from migrating in the past, many of the key blockers have gone away with Microsoft Entra ID now, including capabilities like certificate-based authentication to support smart cards and similar solutions, group filtering to filter groups for specific claims, group transformation that helps you change inputs and outputs in the token, and token augmentation, which lets you query non-identity data, like proof of training completion and insert those claim values into tokens at runtime. Additionally, there are lots of capabilities that you get in Microsoft Entra ID that you can’t do with AD FS. For example, there is conditional access, which lets you specify factors like user risk, sign-in risk, device platform, location, and client apps to determine in real-time and at login to allow or block access.
-Then beyond standard multifactor authentication, phish-resistant passwordless authentication lets you instead use biometrics with Windows Hello, FIDO security keys, and certificate-based authentication without worrying about traditional password management and their associated risks. Now, if you’re still thinking, AD FS is working well for me right now, why change it? There will always be reasons to run AD FS infrastructure, locally. It’s not going away. It’s probably the right choice for scenarios where our devices and servers are fully disconnected from the internet. That said, as mentioned, the list of reasons to continue running local AD FS environments keeps getting shorter.
-Let’s break this down further. While AD FS helps you configure and manage secure sharing of identity information with cloud apps and between trusted boundaries, its core function is really to issue tokens so that services can be securely accessed. This is something that Microsoft Entra ID also does very well, and for most scenarios, Microsoft Entra ID also makes a lot more sense to run. For one, it’s a complete identity solution with a broad set of capabilities, which goes beyond what AD FS can do. And you can achieve the same or even better seamless single sign-in experiences like AD FS, but with more security, flexibility and control, along with a lot less management complexity.
-So let’s also compare the management experience. If you’re running AD FS infrastructure, you’ll be familiar with the effort required to keep it running. This includes all the AD FS Windows Servers or Web App Proxies that you’re likely running on-prem. You need to maintain your SSL certificates, ensure the communication lines stay up and running, apply software updates, as well as DNS and firewall rules. And on-prem AD FS infrastructure is also often a target for attackers because once they’re able to own or issue tokens on your behalf, they control all of your connected infrastructure and services. This effort and risk goes away if you migrate these services to Microsoft Entra. In fact, moving to Microsoft Entra ID also makes connecting cloud apps a lot simpler than setting them up in AD FS.
-And the user experience is also better, where for example, the user doesn’t have to worry about managing different sign-in sights by setting favorites to get to their apps. Everything’s accessible right from the Microsoft My Apps portal, which lets you navigate to all of your cloud and on-prem line-of-business apps in one place, like you can see here. The user’s app list is automatically created based on the apps they have access to, and it can be customized based on their needs. In fact, there are more than 3000 pre-integrated applications that are enabled for single sign-on, so you can connect what you need to make it seamless for your organization. And also from an IT perspective, there’s no need to build a custom internal site or help users navigate to their cloud and internal apps.
-And you can also get a lot more visibility into how your services are running, along with any trending risks. Out of the box, Microsoft Entra ID provides access to detailed usage reports for visibility into the reliability, identity-based risks, and other trending security impacts on your organization’s directory. Additionally, Microsoft Entra Identity Protection gives you a consolidated view into risk detections and potential vulnerabilities that affect your organization’s identities. The service has a guaranteed 99.99% uptime SLA, so you don’t have to worry about keeping the services running, as you would with your own AD FS infrastructure.
-So now that we’ve compared the two approaches, let’s look at what it takes to migrate from AD FS to Microsoft Entra. As I’ll show you, this is a lot more manageable than you might think, once you’ve done the upfront prep. Now you’ll probably have AD FS running with a hybrid configuration, which is true by definition if you’re using any Microsoft Cloud service. To migrate, you can use the free AD FS Connect Health tooling, which helps by discovering your AD FS connected apps as you can see here. It provides a comprehensive view of your active AD FS applications. And as a best practice, you’ll want to use this list to identify which apps are being used and decide what you want to migrate, as well as the apps that need to remain in AD FS; and finally, determine any apps you want to deprecate.
-Let me walk you through how to set this up. I’m in the Microsoft Entra portal under usage and insights in the AD FS application activity blade. From here, you’ll start by downloading AD FS Connect Health to analyze the app usage in your on-premises environment. Next, on each targeted AD FS or Web App Proxy server, you’ll install and configure AD FS Connect Health. Of course, these servers will need connectivity to the AD FS Connect Health service endpoints, so you’ll need to open the required endpoints in your firewall. And all of this communication is secured over port 443.
- Now, once everything is connected and monitoring has been established with Microsoft Entra ID, back in the AD FS application activity blade, you’ll be able to see your connected apps and quickly identify which of your applications are capable of being migrated. In the migration status column, you’ll see it’s automatically assessed all AD FS applications for compatibility. And if you click in, it alerts you of any issues, and within each issue, it provides guidance for preparing individual apps for migration. Now I’ll step through the process using Salesforce as an example. So for any app, you’ll configure settings first in the Microsoft Entra portal, while keeping AD FS services running for that app, so there’s no downtime. And there are tutorials and resources for most common apps that you can find at aka.ms/migrateapps.
-Back in the My Apps portal, once you’ve configured your app in Microsoft Entra and verified it’s working as expected for sign in, you can then start to assign users to the Microsoft Entra instance in the cloud for each migrated app. And with that configured, the last step you’ll need to take is to update the app itself, as you can see in my case from the Salesforce admin settings, where I’ve configured Microsoft Entra ID exclusively as its identity provider. From there, you’ll repeat this process for any additional apps that you have in scope as part of your migration project. It’s seamless.
-Then after you cut over to Microsoft Entra as your identity provider, your users won’t even feel it. And by the way, you can also find out more and get hands-on guidance and detailed documentation for your migration at aka.ms/adfs2entra. Keep checking back to Microsoft Mechanics for all latest updates. Subscribe if you haven’t already. And as always, thank you for watching.
