Retiring ADFS: a phased move to Okta
Moving a mortgage servicer's federated applications from ADFS to Okta one at a time, so ADFS could be switched off without a big-bang cutover.
- Where
- Rushmore Loan Management Services
- When
- 2017-2023
- My role
- Systems engineer: app integrations and troubleshooting
The situation
Rushmore ran hybrid identity. On-premises Active Directory synchronized to Microsoft’s cloud through Entra Connect, and ADFS handled federated sign-in for a set of business applications. ADFS works, but it’s one more server farm to patch, one more set of certificates to roll over, and one more thing that has to stay highly available (because when it doesn’t, nobody can sign in to anything). The company decided to move federation to Okta, with Entra ID still underneath for Microsoft 365.
What I did
- Moved 5-10 applications from ADFS to Okta in phases. There was no big-bang cutover. Each app moved on its own and was working before the next one went.
- Configured the Okta application integrations for each app.
- Troubleshot the problems that always come up in a migration like this: token-signing certificate mismatches, the Okta AD agent losing sync, and Entra Connect synchronization errors (which never seem to happen during business hours).
- Separately, I configured single sign-on for a VoIP application directly in Entra ID, as an enterprise application.
The result
Once the last application was off it, ADFS was retired. That’s one fewer system to patch, monitor and keep certificates current on, and I don’t think anyone missed it.
What I’d tell someone doing this
Move one app at a time. Keep a list of every certificate’s expiry date, and who owns the other side of each trust. In my experience most of the trouble in federation work isn’t the configuration. It’s a certificate rolling over that nobody remembered (usually on a Monday morning).