The Okta user-disconnect from AD is in progress and while the name of this site including the information presented might appear that everything is set in stone, with clear path ahead to remove Active Directory, the truth is that second thoughts do surface.

For instance:

• What about Wifi access control, other authentication requirements for the office (even though not pressing right this moment with WFH (working from home)?
• What about internal DNS (will we still need it)?
• Will this affect the remaining few servers in any unforeseen way?
• Will there any other unexpected consequences that we haven’t thought of?
• Did I forget any services that we take so for granted that I don’t even think of anymore

However, then I also remember why we started this process: The dependency on a a set of equipment, distributed over 3 sites that serves nobody at the moment, but that can affect employee’s ability to work remotely should it fail.

Another argument is to reduce the amount of equipment to reduce the physical and thermal footprint our remaining servers have. To create a light-weight IT backend, that gives us flexibility to work from anywhere, allows for easy office relocations if necessary, reduces required maintenance and the risk for equipment failure.

There are AD alternative cloud based authentication mechanisms available, like JumpCloud or SecureW2 and others that I haven’t “stumbled over” yet. I like to focus on cloud based auth methods to avoid installing/maintaining on-premise directory and/or Radius servers. Let’s continue to tackle this.

Okta is our cloud based IdaaS (Identity as a Service) of choice for the last 3 to 4 years for all of the cloud-based services we consume. Until now it operated alongside Active Directory via its Okta-AD agent software

After making the case for retiring AD and deciding to move ahead with it, the next immediate task was to disconnect Active Directory from Okta. This prevents that any possible equipment or software malfunctioning in our (because of CV-19) “abandoned” offices to affect our employees’ ability to work remotely

Rather than disconnecting Active Directory from Okta in one shot and as a whole, we decided to disconnect every employee from Active Directory in the Okta admin interface on an individual basis.

This allowed us to deal with any unforeseen issues one by one rather than impacting all of our employees at ones. Our small user base of 60 allowed for this procedure. Larger productions sites might not have this “luxury”.

We began this procedure with two test users and monitored any effects on access to our cloud-based applications and followed up with disconnecting our own (2-person IT team) Okta accounts from Active Directory. Going forward any authentication with Okta ends with Okta, rather than being forwarded via the Okta-AD agents to Active Directory.

After communicating our intentions of removing Active directory and why to management and our employees, we set up a schedule for disconnecting all employee Okta accounts from AD. Our plan is to have this first part of the AD removal wrapped up by the beginning/mid July.

This process is pretty straight forward – upon selecting to disconnected the Okta user account from AD, one gets the option to reset the Okta password (recommended method). And the respective user receives an email to reset their Okta account. The user cannot log into the Okta account until their password has been reset. A couple of things to look out for before disconnecting the Okta account from AD:

• Ensure email address in users Okta profile is correct
• Create Okta based groups (they are until now groups that have been imported from AD) and assign respective applications to the group – they basically replace the AD imported groups
• Assign user to new Okta groups

MFA functionality, like Okta Verify, was not impacted by disconnecting the Okta account from AD. The Okta user simply has to reset their password to complete this process.