Category Archives: Virtual Directory

Polar opposites

I recently saw two polar opposite recommendations; one from Jeff Atwood begging you to not write code; and one from Radovan Semančík suggesting that the only practical software to use is open source software that you can fix as needed.

Obviously Radovan’s approach is not a scalable one. While there are a lot of terrible software products out there, especially in the enterprise space, there are also a lot of good ones that just work. Limiting yourself to coding solutions is a waste of time that most companies won’t pay for. Also Radovan’s solution limits you to open source solutions implemented in a language you are familiar with.

At the same time there are some problems that just need a coding solution, or are best solved that way.

 For enterprise solution I am going to thread the path between Jeff’s Scylla and Radovan’s Charybdis by posing these questions:

  • How much coding should be expected to implement an enterprise solution?
  • How can you find enterprise solutions the works well enough you don’t need the source code or extensive customizations?

An enterprise solution that requires you to write code or scripts to do basic functionality is not well designed, in my opinion. Coding or scripting should only be required wheen the functionality needed is unique to a specific deployment (or too uncommon enough to be a main feature of the product). This is a core philosophy at OptimalIdM as well. Although the VIS virtual directory does support .NET plug-ins, most of our customers never need one. When we have seen the need for plug-ins in the past we looked for a common feature that could be added to the product.

So not having to write code one measure an enterprise solution’s quality. Here are some others:

Ease of install – they say you only get one chance to make a good first impression and install time is it for enterprise software. If your vendor is telling you that you need consulting hours just to install the software, it’s not going to get better from there.

Ease of use – requiring training to use enterprise software is a bad sign. Did you have to have training to use your browser or word processor? Enterprise software should be like that.

Stability – once installed and configured the software should just work. Baby-sitting should not be required. And if you really need two weeks of work or the source code to figure out why your solution stopped working, you made a poor vendor choice.

So go ahead and write code, but only when you have to.

Enter the Migrator

One common business case we get is to migrate from various directory servers to AD. This is usually an issue of per user license cost but lower maintenance is also a factor. Companies are realizing that since they are maintaining AD anyway, why pay for and maintain other multiple directory servers as well? For employee accounts it usually doesn’t make sense to have the same account in two places and need additional processes just to keep them in sync.

There are several ways you can migrate directories. You could use a one-time import/export, a Metadirectory, or a provisioning system, but these approaches have several key drawbacks. One issue is that in most cases you can’t migrate the user passwords. Another issue that the migration may require custom attributes to be added to AD (try getting your AD team to agree to that).

But the biggest issue is that these directories exist for a reason. There are client apps, sometimes tens or hundreds, which rely on the information in the old directories. Most home grown apps written for one directory won’t be able to switch over to AD without extensive rewriting. Even commercial apps that support AD may require significant and disruptive configuration changes.

Enter the Migrator (obscure Disney reference intended)

A virtual directory can be your Migrator. The solution is to standup a virtual directory that merges your AD with the old directory into a single view that emulates the old directory. Run both directories side by side while migrating the accounts. When a password change is made the virtual directory can update both AD and the old directory with the new value, so after running side-by-side long enough, most of the passwords will have been migrated. Eventually the old directory can be retired.

This approach has two main advantages:

  • no changes need to be made to the client applications
  • no schema changes need to be made to AD.

There is a good white paper that covers this in detail on the OptimalIdM web site (no registration required).

Pulling LDAP

Mark Diodati sums up the recent SPML threads here. But one questions that needs to be answered, if not SPML then what? One alternative that has been put forward by Mark Diodati, Mark Wilcox, and others is the LDAP (or DSML) pull model of provisioning.

This model is to expose your user accounts via LDAP using a Virtual Directory (VD) instance exposed to your service provider. The service provider would periodically make calls to the VD to look for account CRUD operations.

There are several compelling advantages to this model;

  • LDAP is already a standard protocol
  • There are defacto standard schemas (the most common of which is the standard AD account)
  • This is really just an extension of a model that has already been embraced in the enterprise (look at how many apps can be AD enabled)

Could that be it? Is the solution to service provider provisioning really this simple? No, at least not without SAML. While this model shows promise there is a problem; passwords. If your enterprise is not ready to use SAML to authenticate to your service provider, then you are left with two choices; both unpleasant.

First you could just punt on passwords and force your users to manage their passwords on their own. This is no worse than the situation without any provisioning, but certainly not where you could be if you used a provisioning solution to push the passwords out to the service provider as needed.

The second is to expose your password hashes via your VD. If your service provider supports the same salting and hashing algorithms, then the passwords could be synchronized by copying the hash across. In fact the recent version of the Google apps dir sync utility claims to be able to do just that.

But think about this for a moment. If you do that then the service provider knows the clear text password to log into your network for every one of your users that actually uses the service. After all, the user has to provide the clear text password to the service provider’s login page to generate the hash value to compare to the hash you sent them. If that’s the same as the hash value in AD, then the service provider knows your AD password by definition.

Do you trust Google with the clear text AD passwords? I’m not picking on Google; there simply aren’t any service providers I would trust with that information.

Another alternative I have heard is that the service provider’s login page would make an LDAP bind call back to the VD with the supplied password to do the authentication. Again, that gives the service provider a clear text version of your AD password.

Are you sure you really want to do that?

But if your enterprise and your service provider can implement SAML, then the LDAP pull model looks a lot more compelling. I would be curious to hear from anyone that has implemented this or is thinking of implementing it. And if anyone is using the password hash sync approach, I would be interested in hearing about as well.

OptimalIdM and WIF

OptimalIdM has announce support for Microsoft WIF (you can get more info here). What they have done is pretty interesting. The have created an STS that front ends their Virtual Directory. This allows a single STS to be used to issue claims against multiple identity stores.

Of course the main use case here is the multiple AD forest scenario, but it could also support disparate identity stores such as other LDAP directories, databases, etc.

[Full disclosure: I have done consulting work for OptimalIdm in the past.]

Virtual Directories, O through S

Felix Gaehtgens of Kuppinger Cole has this to say about today’s virtual directory vendors:

As someone actively covering directory services and virtual directories, several innovations have caught my attention. The players within the virtual directory space are (in alphabetical order) Optimal IDM, Oracle, SAP, Radiant Logic, Red Hat, and Symlabs. When it comes to product development and innovation within the last year, you can split those vendors right down the middle. – Optimal IDM, Radiant Logic and Symlabs have been actively developing their product and churning out new features in new versions. The others have not been adding any features, but instead spent time changing logos, product names, default file locations and otherwise integrating the virtual directory products into the respective Oracle/RedHat/SAP identity management ecosystems. In fact, in some of the latter cases I ask myself whether it is likely to expect any virtual directory product innovations anymore.

I couldn’t help but notice that the entire virtual directory space as described by Mr. Gaehtgens spans only five letters of the alphabet (o through s). It doesn’t mean anything, but it’s still odd.

Phillips versus flat-head, for real this time

A while back I wrote this post comparing the argument between Virtual Directories and Meta-directories to an argument comparing Phillips and flat-head screw drivers. I forgot about it until I noticed something interesting. Somehow a lot of readers found there way to the post from a thread comparing Java and C#. But another group of readers found arrived by searching for, oddly enough, information about Phillips versus flat-head screws.

Now I have no more interest in getting involved in the Java versus C# language debate than I am in the Virtual Directory versus Meta-directory debate.

But Phillips versus Flat-head screws? Boy have I got some opinions on that.

If you have to work with existing screws your choice has already made for you (just as if you join a project in progress you seldom get to choose between Java and C#). But if you are starting a project from scratch, you not only have to choose between Phillips and Flat-head, there is also Torx (the commercial name for hexlobular internally driven screws), square, hex, Allen (internal hex), one-way-flat-head, spline drive, etc. Just as you might consider more choices than Phillips and flat-head, you might also consider a myriad of programming languages in addition to Java and C#.

But some are clearly superior to others in certain aspects. Flat-head screws have more driving power than Phillips head screws (Phillips head screws are designed to cam-out to prevent over tightening, an intentional design feature). But flat-head screws are much harder to drive by hand due to tool slippage. This is an interesting analogy to  the ease of development of C++ versus both Java and C#.

Allen and hex head screws have even more driving power than flat-head screws and are easier to user, but suffer from the limitation of needing have the exact size tool to fit the specific head size, whereas flat-head screws can accommodate a wide variety of tool sizes. This is similar to how scripting languages are often limited to use in a specific framework.

Wait, am I still talking about screws?

Mostly authentication

Ashraf Motiwala relays a statistic that %90 of all virtual directory deployments are used for authentication only. If true (and I don’t doubt it), this really isn’t surprising. Most enterprise software doesn’t support LDAP for anything but authentication, and a lot doesn’t even do that.

As I have said repeatedly, this single biggest impediment to enterprise identity management is that enterprise software seldom supports the externalization of identity. And it’s not really the vendors fault. The vendors are spending their development dollars on the features that their customers are asking for. Until customers start making externalized identity a selection criteria, the vendors are going to just do the minimum, which for many is authentication.

For instance in the product I currently work on, ChangeGear, we support LDAP in three ways. We support authentication and user profiles via either Windows Integrated Authentication or generic LDAP. We also support AD for allowing the users to pick lists of impacted users and groups when creating or processing Change Management Requests (RFCs). Lastly we also support AD as one of the means of discovering assets to populate our CMDB.

There are a lot of other interesting things we could be doing with LDAP, but our customers have not expressed much interest in them.