Fundamental approaches to security, device management, and access control are changing.
For the better part of 30 years, these core IT priorities have been inseparable from Active Directory and OpenLDAP, which were excellent solutions in the era of the on-premises domain. But the recent shift to remote work makes it clear that traditional perimeter security and on-prem infrastructure are no longer sufficient to protect an organization’s user identities and confidential data in the cloud.
To better manage modern work environments, we need to reimagine the individual functions of a directory service and separate those functions from the dated concept of the hardwired, castle-and-moat domain. What matters most today is securing the user and the device no matter where in the world they are.
The future of directory services, then, is domainless. Here’s a more detailed look at how we got here, what the domainless enterprise looks like in practice, and the steps organizations can take to modernize their IAM infrastructure.
The domain concept as we know it was essentially architected in the 1990s, and it was an excellent solution for secure user and computer governance in the hard-wired office environments of the time. While most other areas of IT have completely transformed since then, this model still underpins most organizations’ approaches to identity and access management today.
Many IT professionals take the domain for granted and have assumed that the next logical step is to adapt and extend it for the cloud era by adding web application single sign-on (SSO) providers and other identity bridges. But a more practical approach might be to look back at the core problems the domain was initially designed to solve, decide which of those problems are still relevant today, and explore new ways to solve them using modern innovations.
In the mid-1990s through the mid-2000s, office settings were vastly different. Workers entered brick-and-mortar establishments using key cards or actual keys. They walked over to their desks and sat down in front of stationary computers. Those computers were tethered through an ethernet cable to some internal data center or server closet inside the physical office. From inside that central location, the domain controller granted access to IT resources within the local network. That physical network, in turn, was protected from outside attacks by a firewall and by the building itself for physical access.
At the time, this setup was essentially secure and straightforward to manage, and it offered a user experience so seamless that users didn’t have to manage multiple passwords or think about the processes of authorization and authentication happening behind the scenes. Environments were homogenous, with a desktop tower running Windows and Microsoft programs at every workstation. Active Directory (AD) was so well-suited to this type of environment that it was able to give users what was perhaps the first single sign-on (SSO) experience: a single set of credentials to access their Windows-based IT resources through a single system login.
Now, fast forward to the present and tear down all the walls of that building. IT was trending toward flexibility outside the office enabled by cloud technology and widely available high-speed wireless internet. Instead of fixed computers with towers and tube monitors, employees now have laptops and other devices they can take with them almost anywhere, connect to the internet, and start to work. That’s the domainless enterprise in a nutshell, and that’s our current reality.
But in a world where so much work happens outside the domain, IT departments are forced to reassess challenges that Active Directory once handled on its own.
Active Directory has struggled to adapt and integrate with modern cloud resources and non-Windows operating systems, and the perimeter security model it was designed for isn’t enough to protect remote workers.
So the question becomes how to translate the centralized administrative workflow and simple, secure user experience once afforded by AD to a modern environment that includes Mac and Linux systems, web apps, cloud servers, and remote networks, and may or may not still have on-prem infrastructure as well. Users need to connect to their IT resources with minimal friction regardless of where they’re working, and IT admins need to be confident that user identities and proprietary data are protected against attacks.
The problem is that IT doesn’t have nearly the level of control over modern user identities that it would’ve had in a conventional AD domain environment. Applications have migrated from a legacy purchase-once, install-locally architecture to a cloud-based subscription model. Some apps are still installed locally, with identities and configurations handled in the cloud via a web browser.
Left to manage their own identities, users end up with tens – if not hundreds – of passwords, and face the temptation to ignore security guidelines and share or reuse weak passwords.
Users may also be tempted to create their own accounts for new applications as they see fit, without IT’s approval or regulation. This shadow IT poses an unnecessary security risk to the organization. And even identities that are managed by IT might exist in their own silos, with each separate identity requiring its own manual provisioning and deprovisioning process.
There’s no single, central identity analogous to the AD identity of yesteryear. Admins need a new way to secure connections, keep everything safely under IT’s purview, meet security and compliance baselines, and prepare devices for remote work.
When it comes to systems, MacBooks and Linux systems are now commonplace. Where seasoned Microsoft admins once resisted the introduction of Mac systems to the workplace, it’s now standard practice to accommodate those systems. In a traditional Active Directory domain, Mac and Linux system management would not be as flush or secure without the addition of other point solutions beyond AD, such as a system management tool or even an MDM.
Domain environments built around OpenLDAP aren’t fairing much better: LDAP domains and servers primarily manage identities, passwords, groups, and organizational units, but often lack system management, security policy enforcement, and cloud app integration abilities. IT resources have moved on from just using LDAP as the authentication protocol of choice to leveraging modern standards such as SAML, SCIM, OAuth, OIDC, and more. Legacy LDAP environments also require a high degree of expertise to configure and maintain.
The logical way to fill the above gaps in IT oversight is to implement a modern domainless architecture.
The prospect of going domainless might sound a little scary for experienced admins, but a properly configured domainless environment can be considerably more secure than a traditional domain setup in today’s IT landscape. In a domainless environment, the organization’s security posture wraps around each individual user, their Mac, Windows, or Linux system, and the resources they need to access, wherever each of those components is located.
Each IT resource now has its own tight perimeter. This means instead of functioning essentially unsecured within the confines of a hardened larger perimeter after authenticating once, identities and access rights are constantly being checked and verified. Users access their resources directly over a standard internet connection, rather than routing through a domain for authentication. And in place of a domain controller, a cloud directory service handles access management, user authentication, and security enforcement.
It’s this concept of a cloud directory service that makes the domainless enterprise achievable in practice. But even as so many other aspects of IT have effectively migrated to the cloud, many admins have reservations about implementing a full spectrum of directory services in the cloud.
For the most part, that’s because the idea of a directory service itself is so inextricably tied to Active Directory – the existing tool stands in for the individual problems it once solved. And the security aspect of the domain is more intuitive: firewalls and door locks are familiar, and they lend us a feeling of control. It seems logical that giving up the domain would mean increased exposure to attacks and decreased control over security.
But the truth is that even with measures like firewalls, network detection, and endpoint detection and response in place, organizations still get breached. After each new successful attack hits the news cycle, the IT community refocuses on how to enforce a better, stronger version of the same approach to security. Clearly, the old way of doing things isn’t working. The time has come for a fundamentally new cloud-centered approach.
The phrase cloud directory service is used to describe a variety of solutions that fit loosely into the category of IAM, but it’s tough to pin down what this phrase really means from vendor to vendor.
Different cloud directory solutions rarely offer comparable functionality, and almost none of them replicate the full range of AD’s original system governance, authentication, and access control capabilities as an organization’s core identity provider. But that’s exactly what a cloud directory service needs to do in order to support and secure a modern domainless architecture.
In fact, a worthwhile cloud directory service should actually go beyond AD’s original scope by managing access to third-party applications and non-Windows operating systems all from one platform.
This distinction is important in comparing a true cloud directory service to a web app SSO platform, which gives users one identity to access their SaaS applications but may not be able to manage device access, security baselines, or authenticate users to legacy or on-prem resources using their preferred authN protocols. In this sense, SAML-based SSO is just one component of a cloud directory service; the terms are not interchangeable.
Instead of creating a one-to-one translation of the established AD domain model in the cloud, a proper cloud directory service breaks AD’s functions down into their component parts and reimagines each of those parts. If we can separate the individual problems from the solution we take for granted, we can arrive at new ways to solve them.
The following core features are essential to a cloud directory service built for the domainless enterprise:
Many security failures trace back not to the total absence of any one of the above components, but to an inability to apply, enforce, and update them uniformly across an organization. With that in mind, the value of a centralized cloud directory service becomes clear.
Although many cloud IAM solutions are entirely browser based, they’re missing the key to modern domainless security: the device. Users still need a physical gateway to their work, whether that gateway is a laptop, tablet, or smartphone. A great deal of the constant verification required to secure a domainless environment should be handled by the device, using a framework we can think of as device trust.
The idea is that the user logs into the device once, using a combination of password or passwordless credentials plus MFA, and then gains secure access to all of their IT resources. Every transaction is secured and encrypted at an atomic level, so work can be conducted safely over a standard internet connection.
The user experience is similar to the SSO experience of logging into a desktop machine in the late-1990s/early-mid-2000s AD domain, but what’s going on behind the scenes is much more complex and the breadth of IT resources available to access is far greater.
In order for a cloud directory service to establish a trusted relationship with a device, several criteria must be met and constantly reaffirmed. Those criteria simplify to verifying that:
This is where the concept of MFA expands beyond user-facing measures like TOTP tokens and WebAuthn security keys. The above requirements can be confirmed between the device and the cloud directory service, establishing third, fourth, fifth, and more factors of authentication that would be virtually impossible for an attacker to replicate together.
The idea of breaching a network is radically changed by this repeated multi-factor authentication: There’s no longer an unsecured area to traverse during an open session after just one initial authentication. That’s because in the domainless model, security and access control effectively happen at each level instead of only at the network level. Only the right person, with the right machine, accessing from the right location with the appropriate permissions can access data and applications.
A cloud directory service establishes device trust through a combination of GPO-like system governance, software built on the principle of least privilege, and encryption of all data in transit and at rest. Another way to think about this approach is within the context of zero-trust security.
Zero-trust security means the directory service charged with authentication never takes the legitimacy of a user, device, application, or other IT resource for granted. It’s achieved by securing the following four areas: employees, systems, applications, and network.
A system is in place to verify that they are really who they say they are by confirming their password (something they know) and their MFA token (something they have) against the directory database, which serves as an authoritative source of truth.
The system, likely a corporate-issued machine, that a validated person is using to access IT resources must be clean, and the person must rightfully have access to that machine. In practice, this means some sort of mechanism to ensure that the machine is known, policies and settings enforce security standards, and a high degree of certainty that the user is who they say they are. Security software is checked and updated. System telemetry helps ensure visibility that the machine itself is not compromised.
It’s critical that only the right people, on trusted systems, are accessing applications. The logical extension of the above, then, is to verify that the user and machine have rights to the app and to the network that the app is on, and to verify that network’s security. This is where a VPN can sometimes still play a crucial role in the domainless enterprise, as a secure tunnel to an application or resource.
Whatever network the user is on should be as secure as possible, but even if it isn't completely secure, the user can create a secure enclave within that network by using a VPN. Additionally, networks can be secured through additional means such as MFA and even VLAN segmentation.
This idea of a domainless architecture enabled by a cloud directory service and zero-trust security isn’t purely philosophical or some far-off aspiration for the future: It’s here now, and IT teams can begin to implement it right away, either completely or in a gradual stepwise approach suited to their existing infrastructure.
For organizations that are deeply invested in a functioning AD domain, a cloud directory service can envelop the AD instance, providing many of the benefits of the domainless model and serving as a stepping stone to the all-cloud model.
A strong cloud directory service will have the ability to stand on its own as a core identity provider, so even organizations that aren’t ready to go 100% domainless now have the option to move seamlessly off AD when that migration does make sense.
If you want to learn more, explore information about cloud directory services on G2.
No matter how many times we type it in, sometimes we forget our password.
by Mara Calvello
Many businesses use third-party vendors that host, store, process or access information...
by Christopher Gerg
One of the most fundamental decisions about launching your online presence is how to position...
by Piper Thomson
