Wednesday
27Jan2010

Lots new in our virtual directory products version 5.5 (GSSAPI/SASL & Kerberos, HTTP Server Groups ...)

We have just launched a new release of Symlabs LDAP Proxy and Symlabs Virtual Directory Server that delivers many performance enhancements plus a load of new and exciting features, and I'd like to share the information about these significant upgrades with you here.

Our development team has worked hard to create tighter integration with current technologies that are critical to the operation of both large and small enterprises. For example, the new GSSAPI/SASL interfacing capabilities that are included with Symlabs Virtual Directory Server provide significantly better support for Active Directory or other Kerberos-enabled environments, and the new extensions facility which has been added to both products offers the ability to download and install plug-ins as needed for the ultimate in flexibility. And, thanks to major usability improvements, a complete overhaul of the LDAP Browser that was bundled in, and a load of new plug-ins, this latest release from Symlabs is a polished product that is even easier to use. Of course, we haven't forgotten our commitment to industry-leading speed and reliability - version 5.5 is not only better, it's faster.

Core components of both products have been reviewed and tweaked to improve performance, particularly under Windows, while health monitoring and connection pooling capabilities have been updated to improve their functionality and flexibility in addition to performance. But, the major focus for this release has been to enhance usability and provide of new features. As a result, many new plug-ins have been added. There is a new, easy-to-use security plug-in that restricts data views based on simple criteria; various new mapping plug-ins, such as one for DN Suffix Mapping that makes it easy to work with group entries in a virtual tree; plus a number of plug-ins that create Active Directory functionality for the virtual directory, such as the new BackLinks plug-in which can link attributes across entries and the new Victim Attributes plug-in that provides a great way to work around schema modifications. Existing plug-ins for both products have also been updated, with some particularly useful enhancements for the logging plug-ins.

Symlabs Virtual Directory Server v5.5 comes with a host of powerful new features, particularly the GSSAPI/SASL interfacing capabilities - with Microsoft's strong adoption of Kerberos as its central authentication mechanism, adding this functionality to the system administrator's toolbox is a big plus. Using GSSAPI, you can now provide Kerberos authentication on a front-end listener, or alternatively use Kerberos to authenticate against back-end repositories. This means that you are much better able to integrate applications which are not designed to work within an Active Directory environment. Aside from Kerberos, Symlabs Virtual Directory Server also features automatic HTTP server groups, with proper health-checking and appropriate session-handling for failover scenarios already built-in. HTTP server groups open up the possibility to integrate B2B applications via web services as well as with generic XML over SOAP. Not only does this functionality now become incredibly easy to deploy, it also comes with a whole set of HTTP-specific plug-ins to control routing of requests to appropriate back-end servers plus a set of great logging plug-ins.

Many GUI enhancements have been made to both products, most notably the extension manager that now makes it possible to download and install new plug-ins as you require them. For many enterprise customers that require custom development, this will prove to be a massively useful feature. A fully functional GUI configuration component can be designed for any manual processing stage, and the resulting component can be developed for the client by Symlabs, then downloaded and incorporated into an existing version of the GUI to be used just like any other plug-in. This means that new features can be added to the product between full version releases, and that any custom functionality needed by a client to support a new requirement can be made as simple to configure as any of the standard plug-ins.

The DSGUI component for both products now includes better internal checks to ensure that valid or sensible variables are used during configuration, there is now an option to control warning messages for the right level of information, and canonicalization options have been improved and moved into their own advanced tab for a less cluttered interface. Many users will be glad to discover that DSGUI now not only provides a variety of options to integrate with an external LDAP Browser of their choosing, but also comes bundled with with a newly developed, fully-featured, SSL-capable, standalone LDAP Browser. The bundled Symlabs LDAP Browser has a long list of features and functionality, is fully compatible with both Symlabs Virtual Directory Server and Symlabs LDAP Proxy, and can be used with any LDAP or LDAP(S) server (including virtualized) so it's a great choice for an enterprise-wide tool.

The developers have spent a lot of time improving and adding to the logging plug-ins, and they have included a powerful log parsing script in the new release. This script can be used to extract particular log elements of interest for reports that are easier to understand, and for better integration with other monitoring applications that may already be in use throughout the infrastructure. There are also numerous improvements to documentation, including a complete guide to SSL, SASL, GSSAPI, and Kerberos plus a comprehensive manual for the new Symlabs LDAP Browser. The Help system inside DSGUI has also been upgraded so help pages now open in the default web browser, making it easier to step through the content using a familiar application.

These new versions of Symlabs Virtual Directory Server and Symlabs LDAP Proxy are sure to break new ground in the market. I know all our customers are going to appreciate the improvements that have been made throughout, and Active Directory systems administrators in particular will find a lot in this release that is aimed directly at them. Our focus has been on providing better integration tools, enhanced usability, and the best possible performance, and I'm pleased to say that by all accounts we've delivered. Best of all, you can see for yourself - just download an evaluation copy of either one at our website.

Jeff Zukowski

Thursday
01Oct2009

The Laws of Virtual Directories (Part 3)

In the previous two posts we looked at planning, implementing, and supporting a virtual directory environment in the context of Larry Aucoin's Top 10 Laws Of Virtual Directories. As the final installment of our series discussing his blog articles, we want to consider the topic of internal development. While this obviously includes planning, implementation, and support we see it as a separate and important group because it is orthogonal to all these aspects of a virtual directory infrastructure.

  • Law X: A Virtual Directory MUST NOT require custom coding

We think this last law is only partly true. A virtual directory should provide the functionality to resolve most problems without requiring custom code. In our experience, Symlabs Virtual Directory Server deployments are handled using out-of-the-box functionality 99% of the time. The extensive list of included plug-ins that can easily be incorporated out-of-the-box into a configuration is the key to this.

All of our plug-ins are developed in a simple scripting language that allows a client to review the code and understand what it is doing, which means it's also easy customize. And, providing the option to quickly develop custom code puts power in the hands of the customer. It means that solutions can be developed which cater to very specific requirements, and also that the efficiency of solutions can be optimized. But, a 'one-size-fits-all' approach does not work - it results in bloated and inefficient systems that attempt to handle every possible scenario that anyone could think up, but almost always miss one that is unique to your situation.

In our hands-on experience with actual deployments, we have faced and solved many situations where client LDAP applications did not behave well. In most situations, the application behaved in a manner that was fairly unpredictable such that it's unlikely a virtual directory vendor could have anticipated it and coded a solution beforehand. It seems that sometimes there is no way to predict some problems, you simply must find them. You could choose to wait and see if any virtual directory vendor will release a product in the future that deals with your particular issue, or you could take advantage of a virtual directory that allows you (or the vendor) to quickly develop a custom solution that matches your own specific requirements.

By providing the option to develop custom code, problems are resolved quickly and efficiently. There is no need to wait for a vendor to provide a patch or new release. A unique solution can be coded for your requirements without affecting the core of the virtual directory server code, and you can code them yourself if you choose. Our DirectoryScript API is thoroughly documented and includes a very simple Scripting Guide which ensures that you can always take control of your own solution. It's important not to be wholly dependent on a vendor in uncertain economic times - what do you do if a product is locked up and suddenly you don't have access to the all pieces that create functionality you rely on heavily.

Finally, the ability to code your own solution means that you won't exhaust yourself trying to fit a square peg into a round hole. Vendors naturally try to think up the issues that you might want to resolve before you ever get to them, but often the result is that you are forced to solve your particular problem using a tool that isn't designed expressly to fit the specifics of your environment. Most of the time that's not a problem, otherwise we would never even bother to provide any plug-ins at all. But, every so often you find yourself confronted with a situation where the standard plug-ins just don't fit.

So, we think Law X should really read:

  • Your Virtual Directory Server should solve most of your problems out-of-the-box, AND
    should also be extensible and capable of modifications to suit your unique requirements

Fernando García Vegas

Sunday
27Sep2009

The Laws of Virtual Directories (Part 2)

This continues our examination of the Top 10 Laws Of Virtual Directories that recently appeared on Larry Aucoin's blog. As we discussed them internally and considered how our products stacked up against them, they seemed to fall naturally into three groups. Now let's look at the second grouping - implementation & support issues.

  • Law IV: A Virtual Directory SHOULD NOT take long to deploy

This is definitely true. At the end of the day, we're talking about installing some software and creating a configuration that will resolve a given set of problems. As long as the scope of the solution has been clearly defined, we find that Symlabs Virtual Directory Server can be deployed in as little as one hour and normally less than a week.

Most customers like to engage in pretty thorough testing before launching a virtual directory within a production environment, and this often takes time which needs to be accounted for. But, once they see a deployment in action, it is fairly common for customers to become aware of the full potential of the product. With a whole world of new possibilities available, many of them start to change the scope to take advantage of additional features, and this can cause a deployment to drag out.

It is important to be aware that these are not time constraints imposed by the virtual directory product itself, but are the normal outcome when you deploy a new component within your infrastructure and need to be sure that it works the way that you intended.

  • Law V: A Virtual Directory SHOULD NOT increase administration costs

Absolutely - almost a corollary of the first law. For our example, Symlabs Virtual Directory Server is very simple to configure and manage from within a friendly GUI environment. In fact, the many improvements that it brings to an environment means that in addition to not needing dedicated people to manage it, you also reduce the cost of managing other infrastructure components as well.

  • Law VI: A Virtual Directory MUST NOT have a large footprint

This is also quite true. Symlabs Virtual Directory Server only requires around 4 MB of disk space, so we have this one covered. Our text-based LDIF configuration files require no registry entries and ensure that configuration can easily be moved from one instance to the next as required. Much of the processing functionality that the product can be directed to perform is also text-based, in the form of simple scriptlets that clients can easily modify or customize to work in very particular situations.

The core engine required to run a Symlabs Virtual Directory Server instance is coded in portable C and compiled to run on a variety of operating systems, thus avoiding the requirement for additional software to be installed on your system. This also means that our product is highly efficient and offers tremendous performance with less impact on your CPU.

  • Law VII: A Virtual Directory MUST NOT be difficult to support

Another one we completely agree. In our case, Symlabs Virtual Directory Server uses the same code base for Windows 2000, 2003, and 2008, plus Linux, Solaris Sparc, and Solaris x86 as well. This is is one of the benefits of writing code in portable C. Our products can be run on the platform of your choice and, because the code is the same, we have no problem providing support regardless of the environment you run them on.

Furthermore, many of the features built into the product, such as the ability to easily import and export configurations, scriptlets, and log files, make it possible for our support staff to quickly evaluate problems in your configuration instance and resolve them efficiently - without any need for you to get your hands dirty.

  • Law IX: A Virtual Directory MUST NOT introduce too many proprietary elements

This goes hand-in-hand with Law VII. If your solution is cobbled together using too many proprietary elements it will quickly become unsupportable. This is why we like to code from the ground up. Symlabs Virtual Directory Server does not introduce any proprietary data store, caching, or ports, and where we have introduced external libraries, we have tried to keep to open source implementations (such as the OpenSSL libraries). This ensures that if there is a problem that needs urgent resolution, we are not dependent on an external vendor to resolve it. Symlabs is a strong supporter of standards, believes in helping to ensure that they are followed, and has staff actively contributing to the definition of specifications that provide the framework for open standards.

Fernando García Vegas

Wednesday
23Sep2009

The Laws of Virtual Directories (Part 1)

Recently Larry Aucoin, a co-founder of Optimal IdM, posted an excellent two-part article entitled Top 10 Laws Of Virtual Directories on his blog. Larry's points are well thought out and make a lot of sense, and prompted much discussion within our team. As a result, we've come up with a few thoughts of our own about each law, particularly with regard to Symlabs Virtual Directory Server and LDAP Proxy, and (not to be out-done) are kicking off a three part series here to share them.

Actually, it's a three part format not for any competitive reason, but because our discussion generated a lot of ideas, and also we'll review Larry's laws in groups that correspond to activities rather than in numerical order. So, let's start by looking at ones that involve planning a virtual directory infrastructure.

  • Law I: A Virtual Directory MUST REDUCE complexity

This is pretty much a no-brainer. When things are done well, they tend to be simple. Virtual directories are usually implemented in response to some complex infrastructure problem, and their goal is to help remove the complexity. If this isn't happening, you're doing something wrong.

  • Law II: A Virtual Directory MUST NOT create more issues than it solves

We wholeheartedly agree. In fact, Symlabs Virtual Directory Server and LDAP Proxy are designed around the idea of minimal interaction. This means the virtual directory should only have an impact on those requests and responses that require modification. Any other traffic should be left completely untouched. Our products provide enough granularity to specify exactly what to change, so that only traffic related to this modification will be affected. Working only on the elements that need modification ensures that you are working to resolve your target problem, not introducing a range of new problems to your environment. After all, if its not broken, don't try to fix it.

  • Law III: A Virtual Directory SHOULD NOT be asked to solve ALL identity related issues

There is no 'one size fits all' solution. As Larry points out, federation servers, synchronization engines and virtual directory servers are tools that can be used to solve specific types of identity issues, just like provisioning systems, workflow managers, etc. We offer separate federation product for clients with diverse requirements because we're aware that different tools serve different purposes.

It's worth adding here that, while a virtual directory server shouldn't be asked to solve all identity-related issues, you also shouldn't have to pay for a whole set of features that you don't require. This is the reasoning the led us to offer Symlabs LDAP Proxy at a lower price point - so that clients who only need to resolve LDAP-related issues can avoid having to pay for added capabilities they don't need.

  • Law VIII: A Virtual Directory MUST be a VALUE ADD

Nobody should disagree with this statement. After all, who would intentionally buy a product that subtracts value? Both Symlabs LDAP Proxy and Virtual Directory Server offer a massive range of additional functionality that enhances any LDAP infrastructure, even extending it so that it is capable of integrating with alternate systems. They provide the ability to add unique business logic to your data through a large set of plug-ins that can be arranged in a processing pipeline which will deliver any result you want. All of the plug-ins are developed in a simple scripting language and can be modified to fit your particular requirements, so their limits are boundless. You can make use of this functionality out-of-the-box, or invent your own. This is the best possible value that you can add, the ability to be in control.

Fernando García Vegas

Wednesday
09Sep2009

Find A Solution At TEC 2009 Europe

One look at the agenda will tell you that The Experts Conference (TEC) 2009 Europe promises to be one of the most educational events of the year for folks in our industry. And, as in the past, Symlabs is trying to do its part by contributing useful information and demonstrations aimed at both current implementations and future trends. This year, our CEO Antonio Navarro will be sharing the podium with Peter Steiert from E.ON IS GmbH, the IT service provider for the E.ON Group, to discuss infrastructures that go beyond just virtualizing identity data and add a layer of logic within the virtual directory server that can very efficiently implement a business rules engine, certificate management, or a wide variety of easily customizable data manipulation functions.

E.ON IS has developed just such a middleware layer for a major European power company which Peter will review in detail, and Antonio will cover the general case (based on Symlabs Virtual Directory Server, of course) along with specific examples that should be of interest to a broad audience. This is an area that is full of possibilities, and the techniques discussed can be applied to many environments, including Microsoft® Active Directory®, plain LDAP, LDAP over SSL, etc. If you currently utilize or are planning to deploy virtual directory technology you should be sure to attend this session. There is a synopsis of it at the TEC 2009 Europe website, and you can browse the rest of the session topics there as well so you're prepared to take full advantage of the event.

Our team will be on hand to demonstrate application of these techniques and more to create solutions for common Active Directory® problems using Symlabs Virtual Directory Server or Symlabs LDAP Proxy. Stop by to find the solution you need, discuss virtual directory deployments in general, or explore solutions specific to other environments such as PGP Universal Server. They'll also be offering demonstrations and answering questions for those interested in Symlabs Federated Identity Suite, plus providing advice on how to improve the performance of your identity infrastructure by upgrading to Symlabs products - the industry speed champs.

The Experts Conference (TEC) 2009 Europe will be held at the Hilton Berlin on the Gendarmenmarkt from September 14th through 16th, and Antonio and Peter are speaking on the 15th at 11:15 A.M. I hope we'll see you there!

Jeff Zukowski