SQL Server Magazine

In the past few years, directory services have gained a higher profile in business solutions. Novell's increased success with Novell Directory Services (NDS) and Microsoft's introduction of Active Directory (AD) have provided many businesses with enough reason to begin exploring the potential of directory services in their environments. The Lightweight Directory Access Protocol (LDAP) proxy interface is appealing for companies because it offers a wide range of identity information as a virtual replica without the overhead of replicating data and propagating changes across a network.

In 1995, LDAPv2 introduced a standard directory access protocol, and in 1997, LDAPv3 added several features that extended the protocol. (For information about LDAPv2, see the Internet Engineering Task Force's—IETF's—Request for Comments—RFC—1777, and for information about LDAPv3, see RFC 2251 at http://www.ietf.org/rfc.html.) Vendors immediately began to develop LDAP-enabled products.

Unfortunately, you need to carefully evaluate vendors' claims that products are LDAP enabled. One way to LDAP-enable a product is to make the product capable of querying application data via LDAP. For example, Microsoft made querying Exchange Server possible using LDAP. In other LDAP-enabled products, vendors rely on an available LDAP directory to store user data, profiles, and configuration information. For example, Netegrity's SiteMinder and Check Point Software Technologies' FireWall-1 products can use either the proprietary directory services or a third-party directory service, such as Netscape Directory Server, to store user and policy information.

Vendors can easily provide LDAP-query functionality to LDAP-enable products. For a product that maintains a user database or internal directory, making that database or directory available for LDAP queries requires only minor development efforts. However, using LDAP directories is more difficult because LDAP products rely on an organization to have a directory that supports the organization's application-specific needs. LDAP functionality also makes support between products more difficult. After AD becomes prevalent and offers a guaranteed level of service and information that other applications can rely on, a large upswing of LDAP activity is very likely. Currently, three companies have standalone LDAP proxy servers available: Innosoft International offers Innosoft LDAP Proxy Server (ILPS), MaXware Benelux offers MaXware LDAP Proxy Server (MLPS), and NEXOR offers Directory Boundary Agent (DBA).

In this article, I concentrate on a specific implementation of the virtual directory (also called the directory broker solution) known as an LDAP proxy service. LDAP proxy can help maintain control when you need to provide access to multiple LDAP-enabled resources and you don't have a full metadirectory solution in place, or you aren't in full control of the LDAP-enabled resources you need to provide access to. I look at LDAP proxy services in relation to directory services, some available LDAP proxy servers, and limitations and advantages of using an LDAP proxy. I also offer some advice on when to implement LDAP proxy services.

What Is an LDAP Proxy?
An LDAP proxy is a mediator between an LDAP client and one or more LDAP-enabled resources, generally servers. The proxy's role is to transparently direct and transform queries to the LDAP servers, then filter responses back to the client at the time of the query. Examples of LDAP-enabled solutions to use with a proxy are Exchange Server, NDS, and Windows 2000 (Win2K) with AD.

When you have the need, an LDAP proxy will support differing levels of security in authentication and authorization. You can configure fine-grained access controls and filters, which not all LDAP-enabled directories offer, and use LDAP proxy to introduce an abstraction layer between LDAP clients and one or more native LDAP server security solutions. Most LDAP proxy servers generally provide two types of authentication and authorization. LDAP proxy servers will support pass-through authentication based on the credentials supplied with the query or will operate in a super-user or administrative mode, which forces you to implement extra access controls at the proxy server.

Another aspect of the LDAP proxy relates to (and perhaps competes with) the metadirectory concept. To locate a copy of a directory outside a company firewall, you need to set up rules for synchronization and manage the availability of the external directory. Alterna-.tively, the LDAP proxy works through the firewall with the internal directory and lets you dynamically manage the data transformation, data availability, and security requirements. You can also use a plugin (i.e., a pre-plugin or a post-plugin) at the directory server, which effectively intercepts the query at the server, at the entry, or at the exit. Net.scape uses this solution; however, to provide the necessary functionality, this solution requires you to code a program in the C programming language.

LDAP proxies are different from the Java Naming and Directory Interface (JNDI) and Active Directory Service In.terfaces (ADSI), which offer an API for accessing multiple directories from the client. Microsoft offers ADSI as the primary API for programming to the AD and uses LDAP to talk to AD servers. JNDI and ADSI put the responsibility on the client application to manage and understand the various directories they query. JNDI and ADSI abstract query formats through their APIs. Because LDAP proxy servers manage standard LDAP queries, you can still use JNDI and ADSI to query through an LDAP proxy.

Why Use an LDAP Proxy?
In its simplest form, an LDAP query lets you ask an LDAP server for information based on search criteria. You might use an LDAP proxy server to run queries for the following reasons:

• to create a consolidated view of your internal LDAP directory resources
• to provide load-balanced and failover access to your directory resources
• to manage secure access from internal users to external or partner LDAP directory resources
• to manage secure access from external parties to internal LDAP directory resources
• to manipulate or transform infor.mation being passed to and from an LDAP query according to programmed business logic
• to consolidate LDAP queries through one server to avoid referrals that clients are using

The server that handles the query can either respond with an answer, a failure, or a referral to another server, which might have the information.

A referral is one way that clients can search across LDAP-enabled services. Win2K uses referrals to redirect queries for user information across sites and domains, and the client or the domain controller can follow the referral. A problem with referrals is that clients can't always follow the referral because of network restrictions or access restrictions, so the client might still need to query against the other directory. Although you can define referrals from one directory to another, you have no easy way to en.sure that a query will return data in an ex.pected format. And despite support for referrals, the inconsistencies in schema definition and the application requirements for data make creating a reliable, enterprise-ready solution quite complex. If the server can follow the referrals on behalf of the client, you can mitigate the problem of every client and client ap.plication that needs to understand the distributed directory infrastructure to function correctly.

How Does LDAP Proxy Work?
An LDAP proxy works like most of the current firewall-based proxy services and application gateways. However, many firewalls provide only basic packet filtering operations. Even more advanced plug proxies for firewalls don't let you fully manage all the possible protocols that you might want to offer. Because the proxy acts as a gateway for transactions, it can manage the trans.actions (e.g., translate data, consolidate transactions, multiplex transactions, define abstract levels of security, and control the transaction mode).

In an intranet scenario, you can manage access to LDAP resources both inside and outside the organization. In Figure 1, the LDAP proxy server manages access to LDAP directories inside a firewall. An Internet or extranet lets you hide your internal directory re.sources and still provide managed access to LDAP queries. In Figure 2, the LDAP proxy server manages access to LDAP directories from outside a firewall for Internet and extranet solutions. Let's take a quick look at the capabilities of an LDAP proxy server both inside and outside the firewall.

When managing a transaction, the proxy will accept an LDAP connection to a given TCP port from a client, then pass the LDAP query to the server using the rules defined. This query might be an IP-address-based pass-through query, or the query might require address translation. A pass-through query re.quires no translation or manipulation; the proxy merely acts as a relay for the request. When a query requires address translation, you'll need the client to query the proxy on TCP port 389, which is the standard TCP port for LDAP connections. Or, you might need to query another server on port 636, which is the standard TCP port for LDAP connections over the Secure Sockets Layer (LDAPS). This situation might occur when you have intranet clients that need access to a business partner's directory, and the partner's directory will let them connect only using the Secure Sockets Layer (SSL).

   Prev. page   [1] 2     next page