Rethinking AD: The Four Stages of Separation, Part 1

In the first blog of this series, we explained why it’s time to break-up with Active Directory (AD). In the second, we listed the top five things you can look forward to after making the change. So now we’re breaking down the four stages of separation you’re going to experience as you reduce your dependency on, and potentially leave, Active Directory. This is part one of a two part series, find part 2 here.

We developed the Rethink AD Maturity Model as a journey based on the combined experiences of Okta customers. It follows how they’ve successfully tackled IT modernization with a specific focus on reducing their Active Directory footprint. We’ll walk a hypothetical company through the four stages, describe why the various components are important, and outline how Okta can help. Let’s dig into stage 1.

Stage 1—Status Quo: Where are you today?

It started harmlessly enough—a new directory here, a few new domains there. After an acquisition or two, as your organization began to grow, you started running into forests you didn’t know existed.

And the same thing happened with user devices. Everything was fine in the beginning, when everyone had Windows desktops, and it all fit into AD perfectly. However, in recent years, staff started using smartphones, tablets, and Macs, even Chromebooks. Just like directories, it started small at first, but now everyone has a non-Windows device of some kind, and they all want to be productive. And with management hard-charging for more productivity, what can you do?

But now, Pat from the widget team says that they’re building an app allowing partners to place orders directly with the factory to increase deal flow and pipeline efficiency. And Chris from the e-commerce group wants to build a mobile app so that customers can order upgrades based on their current account preferences.

So where are you going to put all these customers and partners? Can they all go into AD? Maybe. But should you? Unclear. If you’re going to add these partners to the domain, they’re going to have access to the same resources as the employees—unless you build yet another domain. And that’s a problem. So you’ll need domains for each. But even if you do that, it requires additional licensing and the costs add up quickly.

AD can be useful for a simple employee access scenario. But only if you’re connecting to on-premises apps, in an on-prem network, using Windows machines, and Windows servers. Basically recreating 1999 conditions. In essence, as the enterprise infrastructure landscape continues to change, AD has not evolved to fit the use cases of modern workforce and best-of-breed applications.

It’s true that for some resources (such as those in use 20 years ago) Active Directory does a good job of managing. But cloud apps and resources, non-employees, non-Windows devices— basically anything modern —are the ones AD doesn’t handle well. More importantly, the security risks and costs aren’t worth it—let’s start on the path of change.

Stage 2—Make sure you’re safe: Extending AD with SSO and MFA

Your organization failed the security audit last week, so the CISO is breathing down your neck. And, now that everyone is using more cloud apps and services every day, you’re tasked with deploying Single Sign On (SSO) for your cloud apps and enforcing Multi-Factor Authentication (MFA).

But the longest list of vulnerabilities came from your Active Directory configuration. It’s default security settings and assumptions are from the 90’s, making your job of securing your global admin accounts, legacy password requirements, and unprotected domain controller back-ups, much harder.

As they move to the cloud, organizations need to up-level their security posture by extending SSO and MFA. And since AD is basically a beacon for bad actors, many organizations want to minimize its overall attack surface.

This is why Stage 2 is all about making user accounts safer. What's the first big step towards achieving this goal? Enforcing Multi-Factor Authentication (MFA).

What’s new with single sign-on (SSO)?

Extending SSO to cloud apps is one of the critical first steps for modern UX and security. It enables end-users to work quickly, and access the resources they need, while providing stronger security. It reduces the reliance on and mitigates the risk of weak and reused passwords.

And while AD delivers SSO, it does so only for desktop apps. For example, your AD Kerberos token can’t log into Salesforce. To migrate out of the data center and into cloud services, you’ll need to push SSO beyond the desktop and into the browser.

In order to use the most modern cloud apps, most companies choose to implement SSO across their cloud application stack, supporting standards like SAML and OIDC. But why stop there? Depending on the organization, cloud resources may have only a fraction of the critical resources end-users need.

Often, this means users are logging into on-prem and cloud apps separately. Solutions like Okta support SSO to legacy on-prem apps from the same dashboard, providing a unified, consistent experience for users.

The result is improved security, better productivity, and reduced admin and helpdesk calls.

Why Multi-Factor Authentication (MFA)?

In the journey from network-centric to cloud security, the user’s identity is the perimeter. Pioneered within the walls of Google, BeyondCorp is a framework that leading security practitioners are embracing. It encapsulates one of the most important modern security philosophies, Zero Trust and applies it to organizations.

Simply put, Zero Trust assumes that no network is safe, and that proof of your identity is the primary line of defense for protecting and providing access to any resources or apps they need regardless of what network you are using to access those resources. And because MFA is one of the more robust methods of confirming identity, it is a critical component for organizations adopting Zero Trust.

But MFA is not easy to do well, resulting in mixed adoption. Some have limited factor support (e.g., token, mobile app, smart card, TouchID, etc.), which is not good for different levels of sensitivity or differing user types. Other MFA solutions have limited device support, meaning they only work on certain types of devices and not others. Others lack a consistent experience across all devices making it difficult to roll out.

The greatest driver of MFA adoption is a good user experience. Unfortunately, these limitations add up to an incredibly poor user experience, limiting adoption.

Fortunately, Okta’s MFA supports a large number of factors, has broad device compatibility, and delivers a consistent experience throughout. This is ideal for companies that support a Bring Your Own Device (BYOD) strategy and maximizes usability across the organization, which is why Okta ranks so highly with customers for MFA adoption.

Stage 3—Get everyone together: Establishing an IdaaS Identity Hub

Only a few people know, but corporate development is about to announce a 2nd acquisition in as many months—it’s going to be all-hands-on-deck for your team. The time commitments for the integration is short, but you must find a way to deliver. This means consolidating a lot of forests, domains, and users in a very short amount of time.

Simultaneously, Pat from the widget team and Chris from e-commerce have grand plans to drive more revenue and increase deal flow. The problem? Their idea means working even more closely with partners and customers, exposing them to important resources and providing them with access to custom apps and workflows. Some of these are cloud-based that must be secured with modern methods, neither of which are in AD’s wheelhouse.

Active Directory was designed for corporate workers

Part of making an organization more efficient and agile is to eliminate complexity and layers. But AD was meant to contain and manage all the workers and resources for a single organization, making work with external directories problematic. Conversely, AD was not designed to easily unify or consolidate users from different organizations. In particular, this has made M&A integration and domain consolidations using AD very difficult, as well as time and resource-intensive.

Active Directory takes up a lot of resources

Active Directory was designed for a world where everyone is a uniform, corporate worker. In the past, these workers used individual workstations. If they didn’t have a computer or an email address, AD didn’t know about them. Over time, AD has become more accommodating of different user types, but at its core, it’s designed to best support a standard, corporate worker. It treats each user as a rich record, with support for a wide range of employee types, roles, attributes, rights, permissions, and policies. In fact, by default, each user record takes up a significant amount of resources, overhead, and storage—whether the user needs it or not.

For the same reasons, using AD to store partner or customer users is a total mismatch. The kinds of attributes and requirements, rights, use cases, accessibility, and security for partners and customers differ dramatically from employees, which is why AD is a poor place to store any type of external, non-employee users.

The overlap between what AD was designed for and what customers need is basically two things: Username and Password. The scalability, social auth, APIs, microservices, and custom attributes have nothing to do with what AD was originally designed for.

Modern businesses need a cloud-based directory

Customers need a modern, unified directory that can easily absorb multiple directories, has the scalability required for customer volumes, and the modern security, automatic provisioning, and policies that partners, customers, and employees need.

Okta’s Universal Directory (UD) was designed for exactly this reason, to support a wide range of user types and resources. With UD, Okta customers can:

1. Consolidate and visualize all resources in one place

2. Manage everyone and everything on one platform

3. Develop its workforce and customer solutions with the same dev teams and deployment

4. Deliver organization-wide initiatives under one identity provider

5. Save significant money on infrastructure support and maintenance

6. Deploy modern security like SSO, MFA, for all users

7. Unify policies, procedures, and planes of enforcement

8. Eliminate complexity and errors overall

UD enables an agile organization that adapts quickly, adopts new technologies instantly, and learns new processes faster than its competitors.

In part 2 of this post, I’ll explain how new trends in infrastructure, and Okta technology partners, are allowing all kinds of organizations to rethink AD. We’ll also provide examples of Okta customers who have successfully stepped through the stages of separation from AD, where they are in their journey, and the wins they’ve achieved.