From the Inside Out: Deploying eDirectory with an LDAP Proxy
Novell Cool Solutions: Feature
By Rob Sabey
Digg This -
Posted: 28 Apr 2004
Making the Most of Your Novell eDirectory Deployment With an LDAP ProxyRob Sabey, Novell partner manager for the eDirectory product line, and Phil Hunt, director of product management at OctetString
Novell eDirectory and Novell Nsure Identity Manager are sophisticated tools that give organizations a more powerful means of managing their identity information. Unfortunately, however, many applications are not designed to take advantage of advanced capabilities such as automatic failover, advanced replication and multi-point load balancing. So like a Porsche in rush-hour traffic, the power of eDirectory and Nsure Identity Manager is often limited by what's surrounding them.
The good news is there is a middleware solution that acts as an LDAP proxy to bridge the gap between the limits of off-the-shelf applications and Novell identity management products: OctetString's Directory Federator Express (DFE). This easy-to-install software helps organizations improve the availability, reliability and security of their directory service infrastructures. Then they can take advantage of Novell products' enhanced features, while continuing to use their current applications.
Here are a few specific examples of how OctetString's DFE can help Novell customers.
|Failed LDAP Request Handling|
Most organizations use a number of directory replicas in their infrastructure. Yet, when an application sends a failed LDAP request to a particular directory, the directory says the data is not available. The applications aren't designed to take advantage of a multiple-directory environment. By contrast, when DFE receives a failure request, it immediately starts re-routing to replica directories until it receives an answer. This method greatly improves service resilience, helping leverage one of the key features that led customers to purchase eDirectory in the first place: multi-master replication.
In cases where directory-enabled applications either have no provision for load balancing or use an ineffective round-robin method, DFE will accept requests from the applications and then intelligently spread them across the entire directory services environment.
Some applications are designed to make a connection to a server on bootstrap and then not relinquish it until the end of the day. When this happens, any normal external load balancing is bypassed, which will cause part or all of the system to slow down and sometimes even crash. By inserting DFE between the application and eDirectory, the application can establish the connection with DFE, and then DFE will connect to the proper server as needed. Once the operation is completed, DFE relinquishes the server connection while allowing the application to remain connected.
DFE is also useful for pooling connection requests. When applications make too many connection requests at one time, they can overwhelm the server -- causing the server to spend all its time answering connection requests rather than serving data. DFE can pool the requests and present them to the directory as a single connection, allowing the server to focus on what it does best: serving data.
DFE also offers significant benefits by taking advantage of some of the advanced reliability features of eDirectory. For example, DFE bridges the gap between applications and the directory environment by actively monitoring remote servers and routing traffic around points of failure. Unlike some connection-based failover solutions, DFE is able to route at the operation level so that operations passing through it to a failed server can be rerouted to a healthy server ? without requiring the application or client to resubmit the failed request.
|Stopping Unauthorized Requests|
Today more than ever, security is a top-of-mind issue, and DFE can strengthen network security by adding an extra layer of protection to the directory infrastructure. By using DFE as the proxy, businesses gain more control over the attributes an application can see. DFE essentially acts as a ?bodyguard? for the directory, preventing unauthorized requests from reaching the directory. It also eliminates permanent connections between the application and the directory, forcing each data request to be authenticated individually rather than using a good request as a skeleton key to allow unauthorized requests.
This point is particularly important as more organizations open sections of their data to trading partners. Often, replicated copies of a directory are placed into a DMZ and secured with access controls. This strategy can be risky and poses potential security issues if an access control is configured incorrectly or the server is compromised.
DFE minimizes the risk by allowing secure, filtered access to directory information without exposing real data in less secure network environments. It can even be set up as a less privileged user for each request to the internal directory, thereby respecting existing directory access controls. In addition, DFE provides full denial-of-service (DoS) protection to directory servers by completely deconstructing and analyzing each incoming request and preventing usage patterns that indicate data trawling.
These are just some of the ways OctetString's DFE is being used by Novell customers such as Emory University/HealthCare, Pfizer, Coca-Cola, Aetna, the State of Pennsylvania, the German Government and the Norwegian Government.
If you'd like to learn more about DFE, OctetString's Virtual Directory Engine (VDE) product that works with Novell eDirectory to provide dynamic joins of fragmented data, or the company's other products, visit its Web site at www.octetstring.com.
FEEDBACK: Which third-party products have helped you better manage your Novell eDirectory deployment? Let me know at firstname.lastname@example.org.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com