Integration, Security, Performance: Why it’s Time to Retire Legacy Directories

Thank you everyone that’s joined. We’ll go ahead and get started now. My name is Wade Emery. I’m the senior evangelist and IAM consultant at Radiant Logic. They did pick the gray haired senior guy today to talk about legacy directories.

What we’re gonna focus on is integration, security, and performance—why it’s time to retire legacy directories. I am gonna use this opportunity to talk about a little bit of a legacy concept here. This has been around for quite a while now, but I think it’s pertinent and relevant to what we’re talking about today, because it really reinforces the reason that the legacy directories you have in place today are not able to respond to today’s market.

The identity access management or identity management infrastructure has exploded in terms of what’s responsible for maintaining applications, not only on premise, but in the cloud, hosted by third parties. We’re not only managing users now, we’re managing employees, but we’re managing non-human entities now. We’re managing bots and service accounts and admin accounts, and we have a large explosion in devices and the Internet of Things. So the idea that the old traditional model is a simple directory to put everything in for authentication and authorization just doesn’t scale, perform, and it’s not as secure as it needs to be to operate in today’s world.

As this complexity continues to expand exponentially, and now with the introduction of AI and agentic AI agents and other functions that we’re bringing into the play here of Zero Trust, it really becomes a complex environment that needs a much richer, more powerful, more dynamic platform for holding identity data. That was sort of the role of the traditional identity LDAP directory: a place to hold all your identity data—AD or LDAP—for authentication and authorization for applications using a simple username and password and some groups.

So how do you know if you have a legacy directory? Well, if any of your platforms have these logos attached to them, these names, they have these particular companies—Tivoli Directory, UnboundID, Oracle Unified Directory—these are legacy LDAP directory infrastructure. This is about a fifteen‑year‑old platform. If you go back to iPlanet and the origination of the whole idea under Sun and SunONE, you get quite far back into the problem.

What’s wrong with this? Why are you picking on these old directories? It’s not anything they’ve done wrong. It’s just that they were designed with a single schema, usually inetOrgPerson, and a single schema means you have one way to represent the data. But the challenge is today that our data now exists in so many different systems and so many different platforms and so many different formats and schemas and structures that it’s impossible to represent it in just one single defined inetOrgPerson schema. You can use “carLicense” for an odd application for an odd attribute, but it gets old pretty quickly. So you need something very extensible that these platforms just don’t understand and aren’t able to build out.

It’s a single structure. I have one hierarchy or a flat one. I have one model for this data. Well, I’m serving multiple masters now. I’m serving multiple consumers of identity data, and those consumers of identity data need their information in different structures. Some need a flat list to do single sign-on. Some need hierarchical data to do controlled access or Zero Trust or privilege‑based access. There’s a lot of reasons to build structure into your system, but you can’t do that with a traditional directory.

They’re a single protocol. They just speak LDAP. The joke, even just five or ten years ago, was you can’t find a programmer under twenty‑five who can write an LDAP query. They’re all using REST now. They’re all using SCIM. They’re all using some sort of HTTPS protocol. So these platforms make it much more difficult to integrate with new systems, new platforms, with the cloud, with all the functionality that you’re gaining in the industry. Now you’ve got this kind of rock in the middle of the river that’s blocking the flow.

They also have limited scalability. We are now managing tens of thousands, millions, tens of millions, hundreds of millions, and theoretically billions of objects. When you start bringing in the Internet of Things, you start bringing in service accounts, you start bringing in non‑human identities, which are growing ten times faster than human identities, you need a really massive scale to handle the kind of identity information you have, because you need to bring it all together and centralize that data so you can gain visibility and observability on that information. You need to be able to see this information holistically, and if your platform can’t scale, if it can’t perform for that amount of identities in the system, then it’s really not functional for this particular evolution that we demand now for our identity infrastructure.

There’s also external replication. I deploy my infrastructure in multiple data centers, maybe in the cloud, maybe on‑premise, maybe geographically around the world. I have to replicate data. I have to copy data from one system to another. This is very difficult, very complex, very heavy to do in a traditional LDAP directory platform, and it is not necessarily always as reliable as you want it to be. We want to look at faster ways to deploy internationally and as seamlessly as possible.

This also requires dozens of servers: read servers, write servers, replication servers. All this functionality requires a tremendous amount of infrastructure. And again, because I have a single schema, single structure, I have one LDAP infrastructure for one application requirement. I’ve got a whole other LDAP infrastructure for another application that needs to see different data in a different way. So I end up creating a very large infrastructure and very large footprints and very large support platforms.

A lot of these are out of support. The vendor no longer supports the platform. It’s no longer something that they’re doing patching on. It’s no longer something they’ll answer the phone on when you actually call to say, “I have an issue with my platform.” So these systems are going farther and farther out of support and less and less secure just on the fundamental layer. It’s really time to replace them.

A lot of them have been acquired and killed. The applications themselves were bought up by other companies, and those applications are really hard to find. Anybody that understands how to use them, anybody on the support staff of that company that knows how to support that platform is long gone. Those applications are pretty much orphaned at this point. You really don’t want your identity infrastructure living on an orphan platform.

So what do we do about this? We need to look at the reason I’m talking about the requirements for this being much broader than just a place to store identity data so I can do authentication with a password and a group membership recognition. We have new dynamics in the identity management space now. As we are getting more and more defensive against breaches and attacks, as we’re trying to meet more government regulations and standards, we’re moving towards a couple of scenarios now or a couple of structures.

Identity Security Posture Management, ISPM, says that your identity security is tied to how you manage your identity data, the posture you have around that identity information: how secure it is, how accurate it is, how well it is distributed, and whether it is centrally managed so you have a source of truth that all of your platforms are operating off of. Then Gartner’s Identity Visibility and Intelligence platform says that it’s great to bring all your identity data together and that you really want to work on cleaning that data up, but you also need visibility. You need to see what’s happening with that data. You need intelligence around that identity data—knowing what’s being used and why it’s being used. You need to be able to deploy that globally within your operation.

If you can imagine hosting this kind of platform—an ISPM or an IDVI platform—it’s not something you’re gonna do on a legacy directory. You need to move your identity data forward into a modern infrastructure. All of this is to reduce your attack surface. As Gartner’s quote here says, starting with a big‑picture view of IAM by establishing identity visibility and observability, you have to be able to see the data. You have to be able to gather it together and make it visible and observable across connected and disconnected systems to discover identities, consolidate access data, and enable advanced identity analytics. All these capabilities are critical to securing your environment in 2025 and going forward, and that’s not something a legacy directory is gonna help you with. This is why you need to move to a modern infrastructure.

If you’re gonna move, then you have to go through a migration and a modernization. Those are usually scary and cumbersome and disruptive, and we don’t do it because we don’t like the sound of those words. So we basically live with a hobbled system that holds us back and don’t bite the bullet to go ahead and modernize our system. But I think the drivers now for modernization are so strong we really can’t avoid this conversation any longer.

If you’re still living on some LDAP infrastructure somewhere in your organization that’s still feeding some data for something, or you don’t have a consolidated identity infrastructure, you don’t have a unification of identity so you can bring in central observability and visualization and governance and control of that identity, then it’s time to think differently. Imagine identity or directory replacement as trading in your old bike. It was a sturdy bike, it had a basket, it got you around town. If you live in Copenhagen, this is your primary form of getting around town. It’s very common there to see lots of people on bikes just like this. But in most of the United States, this is not gonna get you as far as you need to go. It’s a good metaphor for where our old directories really are today. They’re very limited and very narrow in function.

So you’re gonna replace it with a new car. That’s great. Massive jump forward in technology. You’ve got more room, but you’re still limited. You’ve only got seats for five if you squeeze people in. You’ve got a limited range here. If you get to an ocean, you can’t go across it. You have some real challenges. If you’re gonna go through all the work of modernizing your bike to a new vehicle, why not move on to a jetliner?

A Dreamliner jet—why not go to the ultimate? Why not go to a platform that can cross oceans? Why not go to a platform that can carry hundreds of people simultaneously? Why not something that travels the country not in days, but in hours? This is the kind of transformation we’re talking about when going from a legacy directory infrastructure to a modern RadiantOne platform. You’re exponentially increasing the speed, the scope, the reach, and the capacity of the system to operate, and you’re bringing in modern technology that is going to support you far into the future and make it much easier for you to integrate your systems.

So what is the RadiantOne platform, and why should you look at that as an alternative to your existing LDAP infrastructure as you start to replace things? Identity starts with us bringing in sources of identity data. LDAP directories have a very hard time getting in data from different sources because it doesn’t fit into a square‑peg, square‑hole concept. You need a platform that is very flexible, that is platform‑agnostic, schema‑agnostic, and structure‑agnostic so you can bring in data from APIs from SailPoint, from SCIM platforms, from cloud applications, from databases, and integrate Active Directory and LDAP directories. You want to bring different schemas together, bring in your HR data, and bring this data together to build a unified set of identity data.

Traditionally this was all done just to give access management or single sign‑on—or Ping, or SiteMinder, or Oracle Access Manager—the ability to find a user, authenticate their credential, and then find out what groups they have membership in to allow them to access certain applications on the system. That was the primary function of these directories. But today, our requirements for feeding identity data go far beyond single sign‑on. They go out to our IGA system. Our IGA system needs to access the same data in order to operate effectively. It needs to be making decisions on role management, role mining, access reviews, and provisioning based on the same information. Otherwise, your access management system and your governance platform are making different decisions on different data and getting different answers, and those are supposed to be working together, not conflicting.

Your PAM platform definitely needs to see a holistic view of identity across all your sources. Just managing Active Directory and PAM is not enough. Your financial system has highly privileged accounts that are accessing financial data and things that connect directly to money. Those need to be under management. Then, if you look at runtime authorization or Zero Trust—policy‑based access control, attribute‑based access control—all the terms there for saying, “I’m going to go with a least‑privilege model, and then when you come and ask for access to a resource, I’m going to validate you at that moment based on everything I know about you in real time, and then authorize or deny your access,” that’s the direction we’re heading.

Security posture management and Zero Trust are all moving towards a least‑privilege model. We can’t leave standing privileges, because compromising credentials, hijacking tokens, flooding our frames—all these things that hackers are doing now to get past the authentication layer—let them into the authorization layer unimpeded, and we have to build a layer of defense at the authorization layer. But how do you connect these systems together? What platform out there is capable of actually integrating all these sources of identity and feeding the information in exactly the format, schema, structure, protocol, and subset of users and attributes that each system needs, in a way that it thinks the data was custom configured for it?

RadiantOne. This is the RadiantOne platform. It sits between the data and the consumers of identity data, and it aggregates, correlates, normalizes, and allows you to gain visibility into the data at this layer. This is your ISPM and IDVI platform that allows you to do governance around the data, cleanup around the data, data hygiene, and real‑time analytics and measurement of the data. So if something is in the system trying to corrupt your data, trying to move laterally or escalate an account, that can be seen in real time and can be acted on in real time. Through shared signals platforms, the endpoints on top can be notified in real time.

We’re transforming this world from simply a storage platform to a dynamic model to manage your identity infrastructure. This is why it is critical at this time to move forward. Getting a little more into the nuts and bolts, how do you move forward? Traditional models still apply. You want to take an inventory. You want to do some housecleaning. The nice thing about it is that because of the way the Radiant platform exists and operates, you can deploy it in a non‑disruptive manner to run in parallel with your existing infrastructure, start to pull data in, and start doing housecleaning and data hygiene: finding groups that are abandoned, orphan users, accounts that don’t have owners, groups that don’t have descriptions.

All the things you need to do to start building a unified set of identities, you can start then doing the analysis you need to do and the governance around that data that’s required in a modern infrastructure. Use this opportunity to use RadiantOne to clean this data up. Now you’ve got a new storage platform, a new place to hold the data that scales out exponentially compared to traditional LDAP directories, and it’s platform‑agnostic, schema‑agnostic, and structure‑agnostic. You can build multiple virtual views of the core data you know to be true, but represent it different ways for different systems, so those can operate as they feel is most effective for them, in a way that they assume the data was custom built for them.

You then need to test these applications against this. You can point the applications at your new directory—your new RadiantOne platform—and see what outcomes you get. A lot of times in these scenarios it’s not always obvious how the old infrastructure was built. It was done twenty years ago. The person who put it together is long gone. Documentation doesn’t exist. No one wants to touch it. There’s work to do to run testing and validation. Radiant has tricks built in that make that easier.

Once you’re done, you can cut over to the RadiantOne platform as your identity store. This can be done as a weekend cutover when you’re satisfied that everything is absolutely bulletproof, or it can be done in phases, because this can be a non‑disruptive move over. The intent is for things to be as easy and as resilient as possible.

You also want to take this opportunity to really look at your infrastructure and say, “I know my existing LDAP infrastructure today is large, it’s cumbersome, it’s expensive to maintain, it’s fairly brittle, and it doesn’t really serve the purposes of my applications.” Your IT department has had to say no to application owners who’ve come with new applications because your old LDAP infrastructure can’t integrate information from a database or a security system into an LDAP view and give a correlated set of data back to that application to do its authorization, because it’s not built for that.

Now that you have the world at your fingertips, you can redesign what you’re doing. Analyze your business processes. See how your applications integrate, what they use, and what applications you’ve sidelined or shelved that you could bring back into the system and how to bring those online. Start to design a best‑case world. The wonderful thing about the RadiantOne platform is that nothing you do here is poured in concrete. This is a very flexible system. You can build a design today, deploy that design, and decide tomorrow, “Oops, I left out a whole source of identity data.” Now that you have access to that system, you can bring it online, integrate that data, and remodel your design in a non‑disruptive way.

This is not poured in concrete. Nothing here is forever. It’s not like AD where you built an AD structure and schema and have to live with it for the next ten years and hope you got it right. This is built for future‑proofing your environment. Then you test everything. It has a great way of setting up predicted environments. You can build an environment a certain way and test to see if that’s optimized. If it’s not, you can build the environment a different way and test again. Because this is a mouse‑driven platform, all this can be done with drag‑and‑drop, low‑code, no‑code configurations. You can build an environment in hours and run tests against it. You have the ability to do a lot of blue‑green models to see what is the best scenario, then deploy this out into the world in a number of very non‑disruptive models that make sure that your applications actually go out cleanly.

To modernize your identity data with RadiantOne, first think about the foundational layer. There are two components in the foundational layer of RadiantOne. One is the virtualization layer. It allows you to map and create views of the data in the format and structure and schema that you prefer. You may have information in Active Directory, in a database, and in an LDAP directory that’s a user schema, no schema, and inetOrgPerson schema, and you have an application that needs to see a full name and other attributes that it particularly wants to see. You can aggregate that information, remodel that data, relabel it, concatenate information to build strings of data, and then serve that up to that application exactly as it wants to see it.

It’s this virtualization layer that makes all this possible, joining this information together to build a robust, unified view of your environment—this master user record, this entitlement catalog, this user warehouse where you can see everything you have across the platform regardless of where it came from. Coupled with that is the storage layer. This is a layer that was built about ten years ago based on big‑data technology because traditional LDAP wasn’t scaling out. It allows you to cache the data on disk but still maintain performance. It allows you to listen to back‑end changes in real time and propagate those changes through the system. The data you’re getting at the endpoint when an application is querying it is always going to be the most effective and current data available.

These technologies together give you tremendous value and let you operate and build out the RadiantOne platform on top of them. Behind the RadiantOne directory, again, it’s a next‑generation LDAP v3‑compliant directory, so everything you have today works. It’s a highly available version of LDAP. It also supports additional protocols. If you have applications that want to make REST calls to this data or want to get it over SCIM, all this is available for you to expose the data out of the box without additional functionality. You build a view that’s available on LDAP, SCIM, and REST immediately. Your applications, your cloud applications, everything you’re doing with modern development today can access this data. This is a larger, richer, more unified set of information that you’re exposing to all these applications.

Part of the process and challenges of migration is understanding exactly how this old agent system was working, because again, there’s no documentation, the person who built it is long gone, and a lot of times applications made some really weird little requests to see what was going on in the directory before they started making requests for authorization. We used to have a situation where an application would always call the directory on the back end and say, “Is the account enabled?” That was the first call it made. If the account was not enabled, it didn’t make any more requests. It said, “Account’s disabled. I’m not going to authorize this request for access,” and it sent back a failed logon.

If your directory doesn’t know that that request is necessary and you didn’t set that flag, then the application isn’t going to be able to authorize anybody. You can connect Radiant Logic in the middle of this flow today in a non‑disruptive proxy model and capture all that data flow. It’s like Wireshark, sitting and looking at packets go by. You can look at all the communication between the application and your legacy information, and you can document exactly what’s happening. When you start to build out the infrastructure in Radiant, you’re building to the proper exposed attributes and processes that are being used to support that system. This makes it much easier to build out the platform.

Radiant Logic can discover schemas that are being used. You may have extensively extended schema in your directory that was servicing a particular application. That application had good documentation on what it needed, but that’s long gone and lost. Without that extended schema, you’re going to have real challenges getting that application the data it needs. Radiant Logic out of the box will automatically examine and capture that schema so you can operate clearly with that data.

You can then take the existing structure inside the LDAP model and mimic that inside Radiant very easily. It’s basically just a process of connecting and virtualizing the data, and Radiant can make a snapshot or a view of the way that data was structured. You don’t have to go back and hand‑build your environment in Radiant; you can do this automatically with the way the system works out of the box.

You may also have a scenario where you want to reorganize your environment. You may need your data to look a different way for a particular application. There was a customer that had Qumu, which is “YouTube for corporate videos.” Qumu wanted to look at everyone in the organization and authorize access based on job function—region, department, manager, title, and role. This gives people access to certain videos. People in SAP saw SAP videos; people changing tires on giant earthmovers saw different videos. The problem was their infrastructure didn’t have that kind of organizational structure. It was organized for the business, not for Qumu, and they couldn’t use the application.

Using Radiant, a second model of their data was built that looked like what Qumu wanted. Using the same core information, that data was exposed through that model. Qumu was able to function immediately, and people still used regular AD authentication and authorization to get access to resources. This is an excellent opportunity to reorganize, redesign, and rebuild your infrastructure and build as many parallel worlds as you need to meet the needs of different applications. If a new application comes down the road in a year, you can just step into the control panel, spin up a new view, correlate back‑end data together, populate that view, publish it, and that application has everything it needs to operate.

When it’s “D‑day,” how are you going to get your applications to stop using your old system and start using your new system? Now that you’ve set up RadiantOne, built the structure and schemas, and got all the information there, you’ve either synchronized the data in or cached the data, where RadiantOne makes a copy of the data inside the directory and stores that. As the data changes in the directory, it changes in the store, automatically keeping the data synchronized for you.

On the day for cutover, you cut off the cache so that this data is now static compared to the back end, and you simply repoint your applications to the new infrastructure. Those applications see the world they thought they were seeing before. Everything they were doing before works the same, and their operation goes forward seamlessly. This was done at a large publishing house that moved off of eDirectory. They had a massive eDirectory infrastructure. Radiant modeled their eDirectory schema and structure and data formats, brought all the data into RadiantOne, and got it up and running on a Friday. They cut everybody over on the weekend, and on Monday everyone was back to work and didn’t know their back end had shifted off of eDirectory onto the RadiantOne platform. It was that seamless, that easy, that non‑disruptive—and that’s key, because anything like this traditionally has broken the network, broken things, and brought things down. It’s not something business is happy with. Radiant lets you do it in a way that’s very non‑disruptive and very simple.

The benefits of RadiantOne over a traditional directory are significant. It’s fast and flexible. You can search on all attributes. It uses a Lucene index to do bottom‑up indexing. All attributes are indexed. Subtree searches are supported. Performance is on the order of hundreds of thousands of queries per second across tens of millions of objects. It’s a very high‑performance system. When you’re doing things like policy‑based access control, where you need to know immediately who has access to resources based on many attributes, that subtree search across Radiant Logic will come back in milliseconds. Try to do that in a traditional directory and you’ll get a search timed out, and you won’t be able to support a dynamic policy‑based access‑control platform.

If you’re just doing authorization on title and department, no big deal—but how much granular access control are you getting with two attributes? You need to integrate things like whether the person’s training is current, whether they are in the building, whether they are on a secured machine, whether they are currently cleared for the application they’re operating on. All the other things you can think about incorporating into those decisions can be brought in with Radiant Logic.

Replicating data among the nodes to make it highly available and highly scalable comes with block‑level replication, which is orders of magnitude faster than file‑copy replication. This technological boost makes the performance available. It’s highly scalable and highly flexible. You can scale up and scale down as you need to. It deploys in a Kubernetes infrastructure, so you can run multiple nodes in multiple availability zones in a bring‑your‑own‑cloud scenario. You can deploy on‑prem in your own Kubernetes cluster or put it up in AWS, Azure, or Google. There is even a SaaS platform option so you can run it in Radiant’s SaaS infrastructure.

The idea is that you have robust, multiple sets of data running simultaneously. This is authentication and authorization data. Radiant knows it is in the flow that makes business work, so it is built to be highly available and scalable and able to withstand even a regional failure. If the West Coast is lost, the East Coast can pick up the traffic and data seamlessly and continue to provide users with access to information that runs the business.

When you fully deploy Radiant, you’re looking at multiple sources of identity data: information from O365 and AD, Entra, SQL, training information, traditional LDAP, and other third‑party data—some of it possibly hosted in Radiant Logic at another customer or partner. From that you build a master user record, an identity catalog, an identity entitlement warehouse. You bring all that identity together into a common point you can then analyze. The sources of truth are on the bottom. You see what the data looks like when it’s aggregated and what it looks like when it’s normalized. You can do hygiene and data cleanup and push changes back down to the back ends. This is where you master your information and then make that information available in subsets or views of data that each application needs.

You may have LDAP applications out there; you’ll give them LDAP connections. You may have REST applications; you’ll use SCIM or REST to feed daily data to those systems. You may have other applications in your environment that you want to propagate this data to. You can serve multiple consumers of data, whether it’s access management, IGA, PAM, or runtime authorization. This infrastructure that Radiant Logic provides is the bridge between identity data and all the consumers of identity information. It brings you into the twenty‑first century. It sets the foundation for Zero Trust. It gives you the ability to operate in an identity security posture‑management journey to enable identity visibility and intelligence.

This is the core you need. If you’re going to look at legacy directories and a replacement, why not go with the Dreamliner jet as opposed to a bicycle? To summarize, you want to future‑proof your directory. You don’t want to be doing this again in five years. Moore’s Law says that processing power will grow exponentially. The complexity and reach of our software is actually on the same curve. From the original mainframe to the cloud was a big jump. The cloud to Zero Trust was a big jump. Zero Trust to AI has been a massive exponential jump. We’re on a hockey stick, so you need a platform that’s scalable, powerful, extensible, and not tied to anything legacy today, and that’s what the Radiant Logic platform gives you as a foundation.

You’ll be able to address custom data requirements. You’re now serving more consumers for identity data. It’s not just authentication, authorization, and group membership. You need to understand how to extend your dataset, how to build views that feed those Zero Trust and identity‑first infrastructure models. Each application needs data in a certain way that is optimized so IT can say “yes” to everybody that comes to the department and says, “I want to deploy this new app we just bought, we didn’t talk to you about,” or “I have this new application that we’re building on the consumer side, and we haven’t put any security on it at all, but we thought you guys might want to feed us a bunch of data.” That’s where Radiant Logic steps in and saves the day.

Radiant will maximize your ROI. Basically, your existing LDAP infrastructure is holding you back. You bought applications, you’re trying to deploy them, but you don’t have access to all the right data, and the parts don’t fit together. The old model doesn’t fit in the new world. You need something that’s current, scalable, and flexible, and you need to support more than just single sign‑on. You need to go out to fine‑grained authorization and more. You’re building out a Zero Trust infrastructure. Your back‑end foundation needs to support that. You’re going to implement identity‑data hygiene, clean up your environment, increase visibility, and bring in observability, which not only looks at the data and shows it to you but runs controls against that data to say, “Is this identity data acting the way it should? Is this account that’s getting escalated privileges doing this in a way that’s authorized? Is this information accurate? Are there anomalies here? Am I getting breached as I’m watching the screen because I can see things changing that are out of band?” If that’s the case, you can step in and remediate in real time. This is what you need going forward.

Radiant invites you to join in three weeks for a webinar contrasting ISPM—Identity Security Posture Management—and the new Gartner standard, IDVI, Identity Visibility and Intelligence, so you can see how these concepts compare and contrast, what they focus on, what they think is important, and how they overlap. Radiant Logic delivers a full suite of functions to meet the requirements of both of these systems. Keep an eye out for those invitations, and thank you for joining. Radiant appreciates your time and attention, and wishes you good luck. Get ahold of them and let them know how they can help you move your LDAP infrastructure into the twenty‑first century.