Azure AD and Okta Feature Comparison

by | Jul 2, 2022 | Azure, General | 0 comments

At Finchloom, we have seen a lot of our clients ask about whether to utilize Azure AD or Okta. Many of these clients have decided to go one way or the other, and a few times without all the facts about each system presented to them. In this blog, we hope to teach our clients and potential customers about the similarities, differences, advantages, and pitfalls of each platform. We hosted a webinar on this topic, and you can watch the on-demand version here.

Okta and Azure AD mirror each other in a lot of ways, and we get customers that come to Finchloom and tell us “We’re looking at getting Okta to do single sign-on for our applications”. What a lot of companies inquiring about SSO fail to recognize is that if you have any Microsoft 365 license, you have Azure AD which has functionality like Okta built right in. There is no need to purchase an additional service if you already own one. Seeing the breadth of the similarities between Azure AD and Okta is critical to understanding the distinguishing factors between each of the systems. Each section has its own video, but if you would like to watch the entire recording, please click here.

Similarities

Okta AD Agent = Azure AD Connect

    • Okta has an Active Directory agent that can be used to synchronize between Okta and Azure AD; Azure AD has Azure AD Connect. These are each tools that go on servers that sync the domain controller(s) with the cloud. Each take all the users, groups, and passwords from on-premises traditional Active Directory environments and copy them over to Azure AD or communicate back and forth. Both systems are near identical from top to bottom, the setup, installation, functionality, and admin.

Okta desktop SSO = Azure AD Seamless SSO

    • Okta Desktop SSO enables single sign-on from your Windows domain joined computers. If users are on a Windows computer joined their domain, they don’t need to enter username and password to sign into Okta, it is completed seamlessly. Azure AD similarly has Azure AD Seamless SSO, which works identical to Okta in the background. This functionality provides a lot of convenience to end users when signing into a Windows PC. After opening a browser, all the programs and apps that are tied to users’ Azure AD account are automatically signed in.

Okta Delegated Auth = Azure AD Passthrough Authentication

    • Okta Delegated Auth does real-time authentication against Active Directory, Azure AD Passthrough Authentication has the exact same functionality and feature set.

SSO Applications

    • One of the things driving a lot of people to Okta is that they can integrate their own sign-in with a lot of different third-party SAS applications. Utilizing these tools, users can sign into Salesforce, Dropbox, and a plethora of other apps and systems using a single set of credentials. Azure AD has the same functionality, so both Okta and Azure AD can integrate with third-party apps using SAML, Open ID Connect, WS federation, Radius (using an on-prem agent), and/or SCIM protocol for provisioning into third party apps. It is highly unlikely that there is an application out there that can be integrated with Okta that can’t be integrated with Azure AD; but if you do know of one, we would love to know!
    • Additionally, we have seen a lot of customers that love having the portal in Okta where a user can log in and see all the app icons like an iPad, Azure AD has the ‘My Apps Portal’. If users go into the Office 365 portal, they can see all their apps from there, or visit the dedicated my apps portal (myapps.microsoft.com) which lists all the user’s apps in the tile view like what users see in Okta.

Okta Secure Web Authentication (SWA) = Azure AD Password-based SSO

    • For websites that do not support the different protocols for integrating SSO apps, both systems use a browser extension to store user passwords and then automatically fill the login credentials.

Okta Verify = Azure Authenticator

    • Each is a mobile app that users install on their mobile devices to authenticate with MFA. Both are near identical apps, they look the same, function similarly, and have the same enrollment setup process and usage. There are very few differences between the two apps.
    • A question we hear a lot about this subject is “Can the authentication apps be extended to on-prem?”. The short answer is yes. There are several different ways to integrate on-prem apps depending on what type of app. One common way is to integrate MFA with the users’ VPN so that users must use MFA to remotely connect into the network via VPN. This can all be done with Azure MFA, usually utilizing the radius extension, and again, it is the same setup integration as it would be with Okta.

Okta FastPass = Azure AD Passwordless Auth

    • Both programs provide an option to sign-in without having to type in a password, and instead rely on a mobile notification.

Okta Adaptive Auth = Azure AD Conditional Access

    • Set up different rules and policies to allow or deny authentication or enforce MFA. These rules can be based on criteria like a user’s location or IP address.

Okta Access Gateway = Azure AD Application Proxy

    • Another way to integrate MFA and SSO with legacy on-premises applications that don’t support newer SSO protocols like SAML. Users can use Azure AD Application Proxy or Okta Access Gateway to publish these applications and make them available over the Internet without a VPN connection and secure them well with MFA and conditional access policies.

Okta Advanced Server Access = Multiple Azure AD options

    • This Okta tool is for securing RDP and SSH access for administrators into servers, and there are several ways to do this with Azure AD. Both have robust logging capabilities where users can access, view, and search their sign in logs, and generate alerts for different things that they may want to see. They also offer connectivity into SIEM solutions like Splunk or Azure Sentinel.
    • A great use case is when we get customers who want an SQL Server on Azure virtual machine, but they do not want to tie it to the rest of their network. We can add an Azure virtual machine for this client, but don’t recommend connecting RDP over the Internet to Azure. In this situation, what we would instead do is utilize a solution called Azure Bastion. This system allows users to do RDP access through a browser with MFA enforcement and conditional access policies.

Differences

Azure AD can completely replace traditional AD

    • With Azure AD, organizations can get rid of their on-premises Active Directory, but are not able to with Okta because it is not a full replacement. Azure AD is very different fundamentally from a traditional Active Directory, but it encompasses all the features. Transitioning and moving completely from a traditional AD into Azure AD in the cloud has its benefits.
    • Azure AD can take your Windows devices/endpoints and join them directly to Azure AD where traditionally a user’s computer joined to AD which allowed them to sign into that computer with AD credentials. Now, users can join that computer to Azure AD and sign into Windows itself using their Azure AD credentials. There is no way to sign into Windows using Okta credentials because Windows cannot be connected and domain joined to Okta the way it can be to Azure AD.
    • Azure AD has Azure AD Domain Services which gives users traditional Active Directory domain controller functionality as a service, so they can get things like LDAP, Kerberos, and domain join for Windows servers and virtual desktops. Users cannot do LDAP queries against Okta, or join a server to Okta, and it lacks the features that would allow IT Admins to completely replace Active Directory. Organizations that have legacy applications and servers that only work with the traditional Active Directory still have some way to connect them to Azure AD using Azure domain services.
    • If a business needs to build a server in Azure once they’ve gotten rid of their on-prem Active Directory, they can extend with Azure AD domain services and join the server to the domain as they would if they had on-prem domain controllers. It is joined to that domain just as if it was joined to a traditional domain, IT Admins can use group policy to manage the server and log in with their Azure AD credentials, but there are no domain controllers to manage, patch, or update; it is all a service that’s provided to you.

Azure AD Connect can only sync 1-way from AD to Azure AD

    • Azure AD connect is a one-way sync from your local on premises AD to Azure AD. We recommend using Azure AD connect if a business has a traditional on-prem Active Directory that they want to keep around and the business wants to continue to master its users and groups in Active Directory. Creating a user in Active Directory then syncs to Azure AD, but it does not go the other way. The Okta AD agent can sync both ways so users can create and manage users in Okta, and then have them written back to Active Directory. This is however a feature that businesses usually do not need with Azure AD because Azure AD can be a full replacement for traditional Active Directory. If users are mastering their accounts in Azure AD, they have no need to write them back to your traditional AD because all the other functionality is replaced.

Azure AD has Endpoint Manager

    • Endpoint Manager (Formerly Intune) is a full device management solution that Microsoft has natively integrated with Azure AD. This allows users to manage Windows, Mac, Android, and iOS devices with Endpoint Manager, and users can push applications and enforce settings and policies. Okta has no equivalent to this functionality. Formerly, Okta had a product called Okta Mobility Management which was a basic solution for managing mobile devices but has since been retired.
    • A common scenario that we’re starting to see more and more is that organizations do not want users to have full access to their corporate data from personal devices or devices that are unmanaged/unsecured. Businesses need to be able to choose when and on what device users can access company data. The ID provider needs to know the state of the devices, and if they are compliant, managed, and secure. Okta has no way to know the status of a device without integrating a third-party system. On the Microsoft front, it is all within the same ecosystem. If a user is connecting from a device that isn’t registered, they can sign into Office 365 from a personal unmanaged device through a browser and can access their email, OneDrive, and work on documents in the browser, but they can’t download anything because it is a personal device. Blocking downloads on personal devices is one potential use case, and organizational files and data stay within the businesses compliance perimeter and are not allowed to be extracted to personal devices.

Azure AD Conditional Access can easily check for Windows domain-join status. Okta requires a complex cert-based auth deployment.

    • Without having your device managed by Endpoint Manager, Azure AD allows users to set up rules based on if the computer is joined to your traditional Active Directory environment. Computers joined to Active Directory can utilize policies to have a different experience from the non-domain joined computers, Okta does not currently have this functionality. For Okta to be able to tell if your computer is joined to the domain, users must set up a complex certificate-based authentication deployment. In Azure AD, this is a simple checkbox to say, ‘Apply this only if the computer is joined to our domain’.

Okta Workflows has no replacement in Azure AD

    • Workflows is Okta’s low-code solution for building automation around user provisioning and deprovisioning that is wizard/UI driven. IT admins can have different things that happen when a user account get created or terminated, so there is automation where Azure AD does not have a feature that directly compares. There are ways that we can automate things within Azure AD, and we often use Azure Automation for our customers when we’re looking to automate onboarding and off-boarding processes.

You might already own Azure AD

  • One of our favorite topics to bring up to clients is to tell them they already own Azure AD premium. A lot of these Azure AD features are free if you’re using Office 365, and some even work without any licensing whatsoever. SSO and MFA are free for unlimited applications; there’s no licensing required. IT Admins can also integrate with Active Directory and set up the synchronization with their Active Directory for free. Some advanced features within Azure AD require the Azure AD Premium P1 license, but it is included in ALL M365 plans. Anyone that has an M365 plan today of any type has Azure AD premium included. Worst case scenario, users do not have a plan that includes Azure AD Premium and need to buy it standalone; $6 a user for Azure AD premium which is identical to the price for the same features in Okta. Purchasing the licensing on the Microsoft side will cost you the same as Okta, and in most scenarios, it’s going to work out to be less. Smaller customers (>300 users) that have Microsoft 365 E3 or E5 have Microsoft 365 business premium, which in turn also has Azure AD Premium P1. AD Premium is also included with F1 licenses.

How can Finchloom help?

We have the experts and resources on-hand to help to plan and execute any transition or migration between Okta and Azure AD. If a business has apps integrated with Okta and needs help unraveling and moving them to Azure AD, or vice versa, we can help move in either direction. We can also assist with the integration between Okta to Azure AD, so if a business wants to sign into Office 365 using Okta, we can set it up and work through the finer points to that configuration. Similarly, we can also do it the other way around, signing into Okta utilizing Office 365 credentials.

We can provide general guidance and strategy as a lot of our customers engage with us just to learn about what products they should be using, and we can assist with the overall strategy. If anyone out there has a complex environment with multiple Active Directory forests, have grown or shrunk due to M&A activity, or they have complex workflows that they want to try to automate, we can provide a lot of value to these types of clients.

We also have experts in mergers and acquisitions, so if a business is using Okta, but the acquiring company is using Azure AD, we can put them together or migrate to one system or the other. If the decision is to take applications out of one system and move them to the other, that’s something we can help with. It usually starts with determining what the corporate directory for the new combined organization is going to be, if there is going to be a centralized directory that includes all the employees, or if they are going to stay in their own separate systems. Most of the time there does need to be a single consolidated directory, and whether that’s Azure AD or traditional AD, determining what that consolidated directory is going to be is critical. All-in-all, the main point of this blog is before deciding to adopt a new business system like Okta, send us a message or give us a call. Thanks for reading!

Post Views: 11,368