Experiences with migraton from OKTA to Azure AD

Question

I'm wondering if anybody can share some practical experience here:

I have a client making extensive use of the OKTA identity solution for single sign-on to various cloud/web applications (both internal and external) as well as extensive provisioning options (creating users in SaaS apps, adding them to groups etc.). They also use OKTA in combination with Radius to provide MfA for Linux users setting up VPN's and for shell login on Linux (dev-ops) servers. Their sign-in to O365 / D365 is at this stage also federated via OKTA, performing SSO into on premise Active Directory.

When they implemented OKTA 2 years ago Azure AD was not yet mature enough in this area but my feeling is that it since has become mature enough to replace OKTA. We want to make use of AAD Premium for SSO and provision, the Microsoft Company Portal and Azure App Proxy for reverse proxy if internal web applications. We also want to use the NPS plugin for AAD MfA for providing MfA during Radius login requests.

In other swords we will need to make use of just about every tool in the Azure AD box to meet the various requirements imposed due to migration from OKTA (current implementation has unfortunately become a "requirement").

• Does anybody have experience with migration from OKTA to AAD?

• Are their any experiences with extensive use of provisioning options for SaaS apps in AAD?

Any advice, tips, experiences are welcome and much appreciated.

Maegan

What is the reason for you trying to move off of Okta to AAD? Is there something that Okta doesn't provide and AAD does? What kind of efficiencies are you looking to gain? In my experience, we're looking to go the opposite route, from AAD to Okta, AAD support for 3rd party applications seems to be very limited and even though it exists in theory, in practice, you will probably need to hire a consultant that specializes in this to get it done, it is not easily configurable if available at all. Specifics of what you're trying to do might be very different from me, but this was my experience. – Schismatic

I guess this could become a long discussion but for this specific customer the reasoning is as follows: – Maegan

1. About 80% of the customer's workload is from the Microsoft stack; CRM and ERP are in Dynamics 365 and office automation makes use of mainly Office 365. The remaining 20% are mostly SaaS solutions largely used by developers and partly also MS based, for example Visual Studio and Team Services. They further already have licensing for the EMS suite (which includes Azure AD Premium). – Maegan

2. Making use of an all-MS implementation makes architectural sense. It's simpler (and therefore easier to support - we can do a standard "out of the box" implementation for the 80% Microsoft based workload) and provides an integrated solution from front to back - AAD provides context based access with MfA integrated, Intune is integrated meaning the context based access rules can enforce access to, for example Exchange using only manged applications (I.e. Outlook App using Intune MAM-WE). Everything as far as Microsoft applications are concerned "just works". – Maegan

3. The customer's goals wit this project is simplifying the environment in order to make them more agile. While OKTA adds some agility in terms of functionality, it adds and extra layer of complexity to the overall design. – Maegan

Now I agree that OKTA is a brilliant solution, according to Garner number 1 in terms of ability to execute, but Microsoft is catching up quickly (number 2, and number one when you look at "completeness of vision"). As an architect my role is to weigh up the benefits of going with a "point solution" like OKTA (Technically best choice and most options, most mature) to the best fit in the client's future vision (very much Microsoft based) and the overall architecture simplicity and elegance. – Maegan

Azure AD just makes more sense here when weighing the pro's and con's. We can do 90% to 95% of what OKTA can (which was not hte case 2 years ago when they implemented OKTA initially) and the Microsoft solution is much simpler. We don't need to maintain technical know-how of yet another third-party point solution. – Maegan

While I agree that solution like OKTA have much value for the right customer and environment and they are good for innovation and diversity in the IT world my mission here is to find the best fit for the specific customer, not save the world :). In this case I (and the leaders/directors at the customer) are convinced an all-Microsoft stack makes more sense for them. If I was truly looking for the "best" solution, rather than "good enough" I agree OKTA would have been better. – Maegan

The extra 10% functionality / maturity just in't worth the investment in another vendor and the associated licensing. Apart from all of that the decision has been taken and my question was on implementing it, not whether I should be doing it in the first place ;-) ... but I appreciate your comment/question. – Maegan

(sorry for the long post but I thought your question worthy of a proper response) – Maegan

I think you might be (and correct me if I'm wrong) speaking from an IT / Infrastructure Architect point of view? I'm speaking from a custom software engineer's point of view. Our needs are not exactly the same if that's the case. Further more I mainly work on native mobile applications and the AAD solution is lacking in that department a bit. If this part is not a concern for you, which it sounds like it is not, AAD may very well be a great solution for you. – Schismatic

Hi Dmity. Yes, I am indeed looking from an infrastructure architect point of view. And I agree that OKTA is the more flexible offering if that is an important requirement. – Maegan

@AdeKoning we are looking at doing the same thing. Did you undertake this project and would you be willing to share any hurdles you might have encountered? – Dorian