Introduction
Over the last several years, an increasing number of organisations have begun to question the business value delivered by their continued use of on premise directory services, such as Active Directory. As a group of products, many on premise directory services do what they do exceptionally well, assuming they are well managed and you have the relevant expertise to manage them. However, the business value of many of their features is dependent on the assumption that employees are working on a device, attached to a fixed network, accessing applications and services hosted on premise. For an increasing number of organisations, this no longer represents their reality. Nowadays, an organisations most important applications are likely to be SaaS based, accessed over the public internet, by an employee who is working from home, their local coffee shop or even the beach. They might well be using Okta to manage these applications and employee access to them, yet they are still provisioning and de-provisioning accounts through their on premise directory and they are still doing all the work and incurring all the costs required to manage it. This might be because they still have one or two on premise applications, or other dependencies such as providing network access or device management. Or it might be because the idea of moving away from it seems daunting or impossibly complex. If this sounds like your organisation and you are struggling to see the ROI from your on premise directory, this post is for you.
Right now your current identity architecture might look something like this:
Your target state identity architecture might look something like this:
But how do you get from your current state to your target state?
Regardless of whether you still need to use your directory, in the shorter term, to provide access to network services, on premise storage or legacy applications you will want to adopt an incremental multi step strategy and pause after the first step. However if you no longer have any dependencies on your directory at all, you can take the second step immediately. Whichever strategy you adopt, your end users passwords will need to be migrated. This can be done using either an interactive or non interactive approach. Both approaches have advantages and disadvantages and which you choose will depend on a number of factors, including, the total number of users you wish to migrate, the amount of time you want the migration to take and your ability to provide support to users during the process. Neither are particularly difficult to do and neither are inherently risky, or inherently disruptive but both require some preparation.
Preparing your environment
Deciding to move away from on premise directory sourced users, either while retaining your directory for selected services, or retiring it altogether may mean that some of your business processes may need to change. If your directory is currently the source of truth for onboarding and offboarding accounts, you will need to determine what will be the source of truth in the future. For many organisations this will be their Human Resources Information Service (HRIS) product either via a direct integration, APIs or events. (It could also be a different application, such as a CRM, but we will focus on HR here.)
To start using HR as a source, requires you to change the direction of the flow of data before making any changes to your directory, so that rather than importing users from your directory, you are pushing users to your directory. It’s important to point out that this does require some planning. If not least, to ensure that the data you are going to import from your HRIS matches the data your applications use for assignment. If there is a mismatch users may not be able to access their applications.
The consequence of not importing from your directory means that your directory based groups will no longer be imported or populated, so if you are using directory based groups to assign applications you will need to use Okta groups instead. Duplicating the membership of assignment groups is straightforward when done using group rules. You simply create an Okta group which corresponds to each directory group and a corresponding rule which adds members of the directory group to the Okta group, using the membership condition. Once this is done you can disable and delete the group rule.
Note: your directory based groups will hang around for a while but once you remove your directory altogether they will disappear.
The goal is to move to an interim architecture that looks something like this:
The key differences between the interim architecture and your starting architecture are the use of your HRIS as a source and the removal of delegated authentication, meaning that rather than handing off to your directory to authenticate users you are now doing this directly in Okta. This means that you need to either migrate your users passwords (non-interactive), or have them select a new one (Interactive).
Interactive Password Migration
The interactive approach is the most straightforward from the perspective of the IT team, because it is your users who do the work for you, by setting their own new Okta passwords. It involves either disconnecting users from your directory, or by disabling delegated authentication. Disabling delegated authentication does this job all in one go and requires much less work for the IT team, but it also means that the risk of causing disruption is greater. If you want to migrate users a few at a time due to geographical support capacity or to minimise potential disruption, disconnecting users is the option you will need to take. There are a couple of prerequisites, you will need to ensure that all users have both a primary and an active and accessible secondary email address stored on their Okta profile, plus, you will need to communicate with users to ensure they are aware of your plans. If you are using Okta Classic, you can use an Okta Workflow to identify users without a secondary email address and ask them to provide it.
If you are using Okta Identity Engine, you can use progressive profiling to collect, update and validate these addresses.
The policy above is applied to the Okta Dashboard, so once a user has authenticated to Okta they are presented with the following screen.
Once the user has provided a value and selected update an email is sent to the secondary address provided requesting verification.
Finally, if you already have this information in another system which is integrated with Okta you may be able to import the email address directly into the Okta profile.
Once all your user profiles are populated with a valid secondary email address your next step should be to disable user imports from your directory. If you are planning to disconnect your users by group, you can do this by creating a filter to exclude the group you plan to disconnect.
To disconnect users you can use either a simple workflow, or take a manual approach. As soon as you disconnect a user, an email will be sent to both their primary and secondary email addresses prompting them to select a new password and providing them with a reset password link.
This is a good approach to take if you want to take the opportunity to move to a new authentication policy or even to introduce a new factor.
What could possibly go wrong?
From a technical perspective, there is not a great deal to go wrong, in the event that something does, simply reimporting your users from your directory provides a roll back strategy. The key challenges are most likely to be found in the change management process. You will need to have communicated clearly, often and repeatedly with your user cohorts so that they know what to expect. Despite this, there will be users who miss these communications and are caught unawares, or who have expired factors so you need to ensure that you have the capacity to support them.
Part two of this post will cover non interactive approaches which are generally far more transparent to your users, but which require significantly more effort from the IT team.
