Internal users, AD password synch and Virtual Directory

At MaXware, we have a product that hooks into Active Directory to capture password changes. Once the change is captured, we can synch passwords downstream to connected data stores (directory, SQL DB, etc.). Like other implementations of this type of solution, ours requires having a component installed on each AD DC to identify and pick up the password changes. Although it's not generally preferable to install software on Domain Controllers, it serves a specific purpose in this case and AD administrators have been known to give-in to their business counterparts to make it happen.

The underlying need is probably obvious - multiple apps each have associated passwords. And more passwords means more to remember, less likelihood of utilizing strong passwords and higher likelihood of non-secure password practices (written notes, etc.).

As we all know, another way to solve the problem is to implement Single Sign On or Reduced Sign On solutions that enable applications to leverage a common authentication mechanism (or at least a common auth store). These solutions are complicated to implement and costly. And you usually need to find a way to synch with AD anyway since corporate users typically change their passwords using Ctrl-Alt-Delete.

ADAM directories serve as one possible solution for some of this pain. You can implement an ADAM directory to serve as the application identity store or even as a central authentication store and pass authentication request credentials through to Active Directory. This means a single password stored in Active Directory that can serve the network environment as well as the apps that leverage ADAM as the Auth Store. If you centralize the store, you don't really NEED to centralize the authentication mechanism, which might be nice in some cases. In environments with a large amount of custom-developed applications, a centralized mechanism would probably provide significant value even if there's already a common authentication store.

Wouldn't it be nice, though, if you could do the same thing without needing to implement ADAM directories and without storing the AD password in two locations? What if a Virtual Directory could pass authentication requests to Active Directory the way that ADAM does? You could potentially use the Virtual Directory to expose only specific attributes to given applications, reduce the overhead of an additional directory infrastructure, eliminate the need to store the AD password in multiple locations (and the need to install agents on AD DCs) and still achieve authentication to multiple systems using a single set of credentials.

[UPDATED Mar. 8, 2006] - Shorty after posting this, I was informed that MaXware Virtual Directory (along with its competition) does, in fact, support passthrough authentication to AD. I guess I thought ADAM was doing more than a simple bind, which is not the case -- I think I learned that years ago and forgot it again. So, I removed the question on technical feasibility. I guess the question becomes why aren't more people talking about this? It seems like it would be an incredibly useful application of our product.

[UPDATED Mar. 18 2009] - I posted more information about ADAM passthrough authentication.

The Value of Virtual: Part II

For the past week or so, I've been thinking about the value proposition for virtual directory technology (Virtual-D). Since I was first introduced to it, Virtual-D was presented to me as a new way to sync data -- an alternative to metadirectories and traditional sync tools. So, I initially thought about its value in relation to that of metadirectory/sync (as in Virtual-D vs. Sync).

Today, a co-worker and I discussed the significant overlap in the two feature sets and the various scenarios that might call for one or the other. Our enlightened conclusion was that Virtual-D and sync tools are complimentary parts of a complete IdM solution.

Then, on the drive home, a light bulb went on. Virtual-D doesn't replace metadirectory, it replaces... [drum role] directory. Hence the name. In an end-to-end IdM solution where you might want multiple directory instances with application-specific attributes and/or security mechanisms, you can replace much of the cost and complexity of numerous directory instances with a Virtual-D solution.

If the goal is to LDAP-enable an application (e.g. SSO, white pages) with enterprise identity information from existing clean data stores, Virtual-D is much less complicated to implement than traditional sync solutions. It doesn't require another data store and it helps circumvent typical political data ownership issues. However, Virtual-D requires clean, current data.
So, if you don't have good identity data available, you might look to aggregate data from the numerous data sources around your enterprise and to create an enterprise directory (or database). This is probably best accomplished using traditional data sync tools. Then, Virtual-D can use that newly compiled identity data store to expose relevant subsets of your identity data to your various applications. And without the need for additional directory instances. And it does so regardless of the data layout or the technology used by the sync tools.

With Virtual-D in the toolbox, it's easy to see why your metadirectory and your enterprise directory don't actually need to be directories at all. They can be relational data solutions. It's easier to store, manage, and sync data in relational formats. And most companies already have relational database expertise (and usually even licenses). When it's time to expose the data to an application, Virtual-D presents it in LDAP format achieving application interoperability and minimizing risk by presenting only relevant attributes to each app.

The Value of Virtual

I'm working on a whitepaper discussing the business value for virtual directory technology. There seems to be a lot of buzz and some misconceptions about the technology and its business case. MaXware is in the unique position of having both a true virtual directory product and a traditional data-synch product (commonly termed metadirectory). So, I'm hoping we can provide a perspective that, while not completely unbiased, will present both technologies as having real value in certain business scenarios. Perhaps, we'll even lay out the scenario where the two technologies converge. If I had any readers, I would ask what you'd like to see in such a whitepaper. Of course, if you do happen to find this post, please do let me know your thoughts.

Physical and Logical Security Convergence

I read an article today that made me think about the convergence of physical and logical security. I don't have the data, but I would imagine breaches made on physical or hard security outnumber what I'll call soft breaches due simply to the techniques involved. To overcome a physical obstacle, you need only to follow someone through a door who used their own valid key to get in. People seem to back away from confrontation and let you right in. I spent a number of years as a consultant travelling from enterprise to enterprise and at almost every one, people would let me in the building, onto the floor and I could usually just pick cube to sit down and fire up my laptop. No questions asked. I think a fairly simple solution can be implemented to provide a substantial value by connecting physical building security systems to network and/or PC logon. I have some architectures in mind if anyone wants to explore.

The article also reminded me that some of the best sources for new ideas are the organizations and industries that we serve -- and not always the expert community. I spend a lot of time listening to the identity management community. It might be worthwhile to spend some of that time reading trade and industry magazines and listening for real-world challenges that have yet to be solved.

[more info on this topic]