Archive for September, 2009

What you can’t do in under 5 minutes

September 21, 2009

Optimal IdM recently released a video showing just how easy it is to install and configure the Virtual Identity Server.  The video takes just 5 minutes, mainly because, well, that’s all the time you need.  So, I was beginning to think about things that you can’t do in 5 minutes.  Here’s just a snippet of my list:

  • Smoke a cigarette
  • Wash your car
  • Take a shower
  • Make Breakfast (toast doesn’t count)
  • Drink a cup of coffee
  • Commute to work (well, this one wouldn’t apply to telecommuters) – Heck, I’ve seen red-lights that last 5 minutes!!

My point here is that it’s incredible to think of how easy we made the installation and configuration of VIS.  This allow our clients the ability to spend more time on planning and thinking of just how to benefit from this technology, and less time thinking/worrying about how to get the darn thing to work (out-of-the-box).  Be sure to check out some of the other videos in our growing collection.

Top 10 Laws of a Virtual Directory (Part II)

September 14, 2009

This blog in part 2 of my previous blog “Top 10 Laws of a Virtual Direcctory (Part I)“.  I will now cover Laws 6-10:

Law VI:  A Virtual Directory MUST NOT have a large footprint:  Optimal IdM’s Virtual Identity Server, for example, takes up less than 5 MB of disk space.  If you add in the Compliance Management system and the SharePoint integration, it climbs to only 25 MB.  The bottom line here is that VIS uses a single XML file for its configuration information, and relies on NO registry information to function (just a simple Windows service).  For requirements, the 2.0 Framework (or higher), is all you need to go.  Be careful of other solutions that require ugly JVM’s, and/or complicated configuration elements.

Law VII:  A Virtual Directory MUST NOT be difficult to support:  Optimal IdM’s Virtual Identity Server, runs on both Windows Server 2003 and Server 2008 in a single code-base.  For this reason, VIS is easy to support.  No worries of platform supportability here, in fact, VIS is officially certified on both Server 2003 and 2008 (including 64-bit).

Law VIII:  A Virtual Directory MUST be a VALUE ADD:  Since Virtual Directories are in essence LDAP Servers, there is an opportunity to make your LDAP experience “better”.  LDAP V3 has been around since 1997 (that’s a lifetime it technology years).  A Virtual Directory can provide features that should be built-into LDAP (perhaps standard one day in V4).  We like to refer to VIS as “LDAP++”, because it improves the users experience around LDAP.  (Watch for a future blog on LDAP++, or “LDAP on steroids”).

Law IX:  A Virtual Directory MUST NOT introduce too many proprietary elements:  A Virtual Directory should not introduce ANYTHING proprietary to your environment.  That includes proprietary data stores, caching, ports, etc.  Optimal IdM’s Virtual Identity Server, is complete WITHOUT any proprietary elements.  Be careful of systems that include complex proprietary elements.  (Complex & Proprietary = additional administration costs).

Law X:  A Virtual Directory MUST NOT require custom coding:  One of the most comment features of a Virtual Directory is handling joins and merges of data.  If it’s so common, why do vendors require you to write custom code to handle it?  How about caching?  Same problem, some vendors requires custom development just to handle basic elements of virtualization.  Optimal IdM’s Virtual Identity Server, is point-n-click for 99% of all features (with NO coding).  However, extensibility is available and in a common in-expensive langue (.NET).  Be careful of customization costs/efforts of other vendors and the language they require development in.  All this time, I thought Python was a snake….  How many people actually know what “Python” is anyway?

Top 10 Laws of a Virtual Directory (Part I)

September 10, 2009

As more and more people are learning about Virtual Directories, they are asking better questions, so I decided to address them in my “Top 10 Laws of a Virtual Directory”.  This blog is Part I (Laws 1-5).  Stay tuned for Part II (Laws 6-10).

Law I:  A Virtual Directory MUST REDUCE complexity:  If you find your Virtual Directory deployment seeming to be somewhat complicated, then you either:

  • Selected the Wrong Virtual Directory vendor
  • Did not implement the solution correctly
  • Both of the above

Law II:  A Virtual Directory MUST NOT create more issues than it solves:  Yes, there are Virtual Directories on the market that set out to solve problem “x”, but in turn while doing so, create problems “y” (and sometimes “z”).

Law III:  A Virtual Directory SHOULD NOT be asked to solve ALL identity related issues:  For some odd reason, people feel the need to “compare” Virtual Directories with synchronization or federation, then saying which is better.  Each has its own pros and cons and should be used in the right situation.  There is no “silver bullet”, especially in the Identity Management space.

Law IV:  A Virtual Directory SHOULD NOT take long to deploy:  When selecting the right Virtual Directory for you, be careful if you are using a System Integrator (SI).  VIS can be deployed in as little as a few hours and normally no more than a few days (depending on the span of the project).  SI’s are only after deploying (and therefore recommending) products that increase their billable time.  They are often times NOT interested (i.e. incentives), on necessarily recommending the “best” solution for a given client.  Sad, but true.

Law V:  A Virtual Directory SHOULD NOT increase administration costs:  A Virtual Directory that requires you to hire more people just to manage/maintain it…is a bad choice.  In actuality, a “good” Virtual Directory (like VIS of course), should effectively “decrease” administration costs.  VIS does this through compliance and automation elements that are built into the product.  Another example is the tight integration that VIS has with SharePoint.  Don’t be afraid to ask your vendor (and their references) how much administration is needed.

Please watch for Part II in this series for Laws 6-10…

You don’t have to have multiple LDAP’s to benefit from a Virtual Directory

September 4, 2009

I can’t wait for part III of Bob’s blog series on “Why are Multiple Directories Deployed and Virtual Directories Ignored?“.  I’m afraid that people will associate using Virtual Directories only to solve the multiple-directory problem as being the only use, when in fact; the uses go on and on.

A Virtual Directory can provide significant value to clients whether they have a single LDAP, or hundreds of them. As I mentioned before, the perception is that “…if I only have one LDAP, then why would I bother with a Virtual Directory?” Well, I could ask the question “…is there any value in using a database view if I only have a single table?” or if I have a single web server, is there any value in using a reverse proxy? The answer to both of those questions is obviously YES, and likewise to that of a Virtual Directory in a similar scenario.

Oddly enough, the benefits in using a database view and the benefits in using a reverse proxy are the EXACT same benefits in using a Virtual Directory. Think about this:

Database View:

  • Provides the ability to filter out data that you don’t want to publish to the consumer of the data (Data loss/leakage Prevention).
  • Provides the ability to perform data translations to the data in real-time. This includes changing the names of fields to either obfuscate them or simply make them easier for consumption.
  • Provides the ability of an added layer of security to the back-end tables. They can be read-only or updatable.
  • Provides the ability to join like data from other tables in a merged view.

Reverse Proxy Server:

  • Provides the ability to mask the server names (obfuscation).
  • Provides the ability to join multiple back-end web servers and host them under a consolidated namespace.
  • Provides the ability of an added layer of security to the back-end web servers
  • Provides the ability of additional caching of information for performance gains of high-traffic websites.

So, I listed 4 common benefits of using a database view and 4 common benefits for using a reverse proxy. My list is obviously not a comprehensive list, but rather just a small sampling of the benefits. Ironically, ALL 8 benefits (there is some overlap), are the same EXACT benefits to using a Virtual Directory! Here is an updated list for Virtual Directories (again, most of these benefits have nothing to do with the number of LDAP’s you have either):

  • Provides the ability to filter out data that you don’t want to publish in LDAP searches (Data loss/leakage Prevention).
  • Provides the ability to perform data translations in real-time. A great example of this is virtually changing the OU structure of your data. Here you can flatten hierarchical data and conversely convert flat data to a hierarchical structure.
  • Provides the ability of an added layer of security to your back-end LDAP data. In addition, VIS provides auditing and reporting as well.
  • Provides the ability to join data from back-end LDAP’s (as well as other types of data stores such as databases, etc.).
  • Provides the ability to mask backend LDAP’s (and provides automated failover/redundancy as well).
  • Provides the ability to merge back-end data into a consolidated namespace.
  • Provides the ability to cache certain data to increase overall performance. (This topic is a blog or two on its own). A good example of this is an application (such as SharePoint), continually pulls data from AD on the user that is currently logged in. Enabling cache (say for just 5 minutes), could save hundreds of back-end searches to AD!

The bottom line here is that as scary as Virtual Directories sound, the benefits they provide are already in wide use today. It’s all about applying the technology in the proper way.

Virtual Identity Server | “The .NET Virtual Directory”

Why not use a Virtual Directory?

September 2, 2009

Bob Bobel from Quest posted an interesting blog today, posing the question “Why are Multiple Directories Deployed and Virtual Directories Ignored?“.  Basically stating that based on the concept of what a Virtual Directory provides, that everyone should have one (or want one).  In his quest to find out why clients don’t have or don’t use a Virtual Directory, his general feedback was that “it just doesn’t fit our needs”.

Hmmm, that’s interesting that this would be the hightlighted response.  In our experience, when talking with organizations (with multiple LDAP’s), most people really don’t know what a Virtual Directory is and exactly what one can do for them (although, they don’t want to seem behind on new technology, so they say things like “it just doesn’t fit our needs”).

It really all boils down to the lack of education on this emerging technology and the fact that there really isn’t much information on how they work or where to truely discover the benefits.  When Microsoft comes in to help a client solve technical challenges around LDAP (AD, AD-LDS, Multiple-Domains/Forest, etc.), they mostly won’t recommend technology that they don’t have to sell.  So clients miss out on opportunities to get educated on newer technologies that can help in certain situations.  For example, Microsoft will almost always recommend to synchronize instead of virutalize, because that’s all they know and sell.  Makes sense to me, but the client loses here by not always using the right tool for the job.  Take a look at this for a quick guide to using a Virtual Directory.

Anyway, I look forward to part II of Bob’s blog on this topic.