Since the introduction of Active Directory Federation Services (ADFS) in 2015, companies have been widely adopting the idea of using this technology to leverage claims-based authentication to provide a means of single sign-on for different services within their own organization or even others.
At a high level, ADFS allows a user to authenticate with Active Directory credentials from their own organization, while simultaneously providing access to a claims-aware service such as Microsoft Office 365, Salesforce, etc.
This means that applications both on-premise and off-premise can be accessed using a single factor of authentication. While this makes for a simplified means of password-management and access management for end users, meaning they will only have to remember one password, it introduces a high level of risk. If the user’s Active Directory password is compromised, any of those services will now be accessible to the malicious entity that captured the user’s password.
Some of the claims-aware services offer a means of providing multi-factor authentication (MFA). For example, Microsoft offers Azure MFA as a solution to provide multi-factor authentication to their various service offerings such as Microsoft Office 365. One problem with Azure MFA is the cost associated with it.
Microsoft offers different pricing levels for their Azure MFA offerings, but depending on the size of the organization, and/or the number of authentications processed by Azure MFA, these costs could grow very quickly. Below is the pricing model taken from the Microsoft Azure pricing site:
There are other companies who offer services that acts as the Identity Provider (IdP) to federate with other organizations or service providers (SP) to handle the single sign-on.
One of the most popular companies offering such services is Okta. The benefit to moving Okta is that the “Okta Verify One-Time Password (OTP)” is now included for all single sign-on customers.
Okta touts themselves as Always-On, meaning there is little concern for maintaining uptime for an on-premise ADFS environment to provide single sign-on. For this reason, many organizations are moving towards Okta for all their Security Assertion Markup Language (SAML) needs.
It is important to note that there is a bit of lead time to move all existing services to the Okta platform. Often times, organizations will leverage a professional services engagement with Okta to help migrate services to the Okta dashboard.
So, what can these organizations do to get the benefits offered by Okta for multi-factor authentication today, to bridge the gap between the time it takes to move all their services to the Okta platform?
Ideally, organizations can leverage Okta for multi-factor authentication without the need for major infrastructure overhaul. Fortunately, Okta offers the Okta MFA for Active Directory Federation Services (ADFS) *This is an early access feature*.
What this provides for organizations is a means to perform multi-factor authentication through Okta with existing on-premises ADFS environments without the need to make major changes to existing infrastructure.
This multi-factor authentication feature can be added to any existing service offered through the ADFS platform, even if the Service Provider does not offer a means of multi-factor authentication.
This is achieved by simply installing an agent that resides on your Active Directory Federation Services (ADFS) server or servers. Once the agent is installed, it must be enabled as a multi-factor option within the on-premises ADFS console.
Once the Okta MFA agent has been installed and configured, an organization can synchronize their Active Directory Users and Groups to the Okta dashboard using Okta’s AD agent. With this agent, it is possible to select which users and groups synchronize to Okta.
Once an organization has the users and groups are synchronized to the Okta dashboard, they can begin to leverage Okta’s MFA. This provides significant security for the existing ADFS environment because an attacker would not only need to compromise the user’s password(s), but also compromise their second factor of authentication.
Okta allows for various means of second-factor authentication as well, which can be selectively enabled for users within the Okta dashboard.
After the user logs in to their organization’s ADFS web interface with their Active Directory credentials, they will be prompted with options for a second factor. Some of the options and screen shots of the user experience are presented in the images below:
Voice Call:
SMS Code:
Okta Verify (Push):
Okta Verify (Code):
One great feature of Okta’s solution is that they make a Developer/Preview environment that can be leveraged for free as a demo. Organizations can use this preview platform as a sandbox or TEST platform for moving their services to the Okta dashboard.
This option can be found at https://developer.okta.com and provides a great option for organizations looking to familiarize themselves with the platform or to simply “test the waters.
In Conclusion
With Okta MFA in place, an organization can protect their ADFS environment and services provided behind it. This ensures that a much higher level of security is maintained for their end users.
With the peace of mind knowing that the existing environment is more secure, organizations can take the time needed to deploy better solutions to their end users and maintain the highest level of satisfaction.