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).
Large organizations often have a firewall in place that the security services group implemented in a locked-down design. In this design, the fire-.wall disallows all traffic, letting ports and protocols through on a request-only basis. Most firewall solutions don't enable standard LDAP ports or the LDAP protocol; therefore, clients can't query for addresses using the protocol. You might need to use multiple host queries to consolidate an LDAP query. Or, you might query several LDAP servers simultaneously (to return the result as if it had come from one server) to multiplex a transaction.
You can use the LDAP proxy to implement several areas of security functionality. Although all functionality isn't security specific, you can use LDAP proxy functionality to control the range of the query.
Query manipulation. An LDAP proxy has the ability to manipulate the in.formation that the query passes and the results of the query. The available solutions currently support some rudimentary capabilities, but the potential for ad.vanced capabilities is great. Using LDAP proxy, you can ensure that certain queries can't use certain attributes. Or, you can ensure that queries don't return certain attributes (such as a directory area) in a result set. For example, you might want to prevent external queries from determining a home phone number for an object, which represents a person in the organization. In this example, you can exclude all queries for the Home Phone attribute and ensure that the proxy doesn't return the Home Phone attribute in a result set. Screen 1, page 104, shows an LDAP query against the native directory using Microsoft Outlook. Screen 2, page 104, shows the results from an LDAP proxy query against the same directory. In Screen 2, some previously available attributes, such as Home Phone, are no longer available and appear as NA. This change occurred because I made the second connection from an external IP address.
Let's suppose you want to enable an internal query to return more information about an object, and the object's in.formation comes from the user-object's distinguishedName (DN) attribute. Here, you can put in a transform to translate the information as it passes from the LDAP server to the client. (I use transform to describe LDAP proxy using the transaction data to modify the query or the result set.) For an organizational.Person object, let's say DN defines the manager attribute of the object. To return information about the manager that includes the manager's full name and phone number would require two queries from the client. You can use a proxy to obtain the same results with one query without overloading the client. The proxy returns the queries as separate values and requires that the client application is ready to receive them.
When performing extranet queries, you'll want to protect your organization's email addresses from exposure to senders of unsolicited commercial email (UCE). To prevent outsiders from ob.taining addresses from the directory, you can use a generic department address. When a secured solution is in place and you need to obtain data on a subject, such as the subject's public key, an extranet query will work only if the person performing the query references the subject's full email address.
MaXware Benelux has the only LDAP proxy server that provides programmable transforms. MLPS lets you use VBScript to define the data transforms. Although VBScript limits the definition to one input and result, the potential for detailed definitions is great. You can use a data transform to obtain data on an attribute called mail, where the source LDAP directory stores the information in an attribute called rfc822mailbox. In this example, you can choose to have the query return the value only when the person's department is sales.
Screen 3 shows the User Group dialog box that you use to configure how the proxy applies the query and passes the transform to the server and how the proxy applies the transform to the data that the proxy returns to the client. You can also use the User Group dialog box to convert data as the proxy passes the query. Screen 4, page 106, shows the code for the data transform of the Home Phone attribute of the Archie Reed Properties that Screen 1 shows.
You can also use LDAP proxy server when internal clients need to query multiple LDAP directories on the Internet and the clients need LDAP proxy to act in a directory mediator role. In this case, you can set the proxy to search multiple LDAP servers on behalf of one query and return very specific information, such as the email address. Screen 5 shows the results in an Outlook client format that this scenario can return.
When you want to search all the directory servers, you'll need to configure your client to talk to all the servers. Because each client query is a separate action, you can put too much burden on the user of the client. You can implement a solution in which the client talks to all the servers to increase the usability of your LDAP-enabled clients, especially email clients.
Access controls. All the proxy server solutions provide some form of control over the type of operations that you can execute against the directory. In some cases, you might want to ensure that clients can't perform any type of write operation. In other cases, you might want to ensure that some clients can't perform reads against secure directories. Depending on the product you choose, you can control permissions by IP address or by authenticated logon. DBA manages connections based on IP address and port number and doesn't provide security control based on authenticated queries.
Protocol encryption. ILPS provides support for Transport Layer Security (TLS), which is the SSL 3.0 Internet standard. SSL is the cornerstone of se.curity in the HTTP protocol that Web-based transactions use. TLS and SSL.are incompatible, but TLS provides a mechanism to support current SSL solutions. Because TLS and SSL are protocol independent, you can use them for most Internet protocols, including LDAP. SSL is more common, but TLS is becoming more prevalent.
For a client to connect to an SSL-enabled server, the server sends a certificate that a Certificate Authority (CA) signed to the LDAP client to make its identity known. Then, the client must determine whether to trust the cer.tificate (e.g., check the trust relationship with the CA that signed the server's certificate).
ILPS provides a mechanism to self-sign a certificate to support LDAPS (available only in the United States), which is equivalent to generating and signing your own certificate for use in securing the LDAP protocol conversation. At press time, MLPS didn't support SSL, but MaXware Benelux plans for MLPS to support SSL in the next year.
You also might want to use Simple Authentication and Security Layer (SASLÑÐdescribed in RFC 2222) support. SASL lets you add methods other than simple authentication and SSL for authentication. ILPS supports SASL. MLPS doesn't support SASL, which re.quires LDAPv3. Although MLPS supports LDAPv3 queries to servers, MLPS only supports LDAPv2 queries from clients.
Failover. You can use an LDAP proxy to create a management point for load balancing and failover. For example, with ILPS, you can specify a load-balance property that can balance queries across several servers, and more important, identify and manage a scenario in which one or more servers aren't available. In the case in which a server is no longer available, the proxy will direct queries to the available servers until that server becomes available again. Unfortunately, ILPS provides no dynamic failure notification (such as SNMP) now, but it might in future releases.
Consolidated logging. A method that provides consolidated logging across directory servers is rarely available, so LDAP proxy provides a consolidated view of directories. The LDAP proxy server products offer varying levels of logging but keep the logs in the same place. If you have directory access to multiple directories using the proxy, you can begin to gain a consolidated view of the directories' use. To use the consolidated view to help solve security problems, you can redirect all LDAP queries through the proxy for a specified time and use the query type to direct the query to the appropriate host. You gain an overall view of the queries' construction. Other than application notes in the system logs, notes in the application logs, and the basic logs in text format, only limited use of native Windows NT monitoring tools is available. ILPS stores logs in syslog format. To monitor the syslog files, you can use tools such as the UNIX Swatch, but NT fares badly using this tool.
LDAP Proxy-Server Solutions
LDAP proxy-server solutions are vendor specific and offer little advanced functionality to compare. However, each LDAP proxy offers the same base functionality of accepting multiple LDAP client requests and returning the query results from one or more LDAP servers.
ILPS. ILPS is available for NT and Sun Solaris. I evaluated ILPS 2.0 for NT. ILPS 2.0 supports LDAPv2 and LDAPv3. No GUI is available other than at installation, so you manage ILPS through configuration files. Although you can use .ini configuration files, Inno.soft also offers the ability to use LDAP Data Interchange Format (LDIF) files for configuration. This capability lets you use an LDAP-enabled directory to store the configuration. In testing, ILPS was the fastest LDAP proxy server; however, ILPS didn't provide the most streamlined functionality. ILPS lets you change attribute naming, set attributes to query, and set attributes to return in a result set. However, the product doesn't provide any method for transforming data as it passes through the proxy.
To support referrals to the proxy, ILPS manages the referral on behalf of the client, ignores the referral, or passes the referral back to the client. This functionality is important if your clients don't support LDAPv3 (because the client won't know what to do with a referral). You conduct management through groups, based on the IP address or domain name. A client might belong to several groups based on this information, but the proxy server uses only the first group that matches the direction of the query. Management through groups creates a way to manage priorities and limit which clients can see the LDAP servers. The proxy will then use the credentials that the client passes, or you can configure the proxy to use anonymous binds for all connections that pass through.
MLPS. MLPS should be available by the printing of this article. MaXware Benelux is the only vendor to provide VBScript capabilities to manipulate data as it passes through the proxy.
I evaluated the MLPS beta, which supports LDAPv2. (MaXware Benelux plans for MLPS to support LDAPv3 later this year.) MLPS provides a simple GUI, which makes configuration easy. The proxy runs as an application, not as a service, which might make implementation difficult for some administrators. However, MaXware Benelux plans to add the service capability. MLPS uses groups to manage permissions for viewing servers. The server bases groups on the IP address and LDAP credentials that the proxy passes from the client.
DBA. I was unable to obtain a copy of DBA to evaluate for this article. However, DBA is available on both NT and Sun Solaris and provides configurable user restrictions and filter implementation. NEXOR also offers Directory Guardian, which is more X.500 specific.
Reminders and Recommendations
LDAP proxy servers offer a more controlled and secure way to obtain data from your directory services via the Internet, an extranet, or a secure intranet application. LDAP proxy servers are still in the formative stage. Yet LDAP proxy servers provide several functions unique from traditional firewall functionality, including event notification. You can expect to see LDAP proxy services improve in the next year. I hope to see the addition of higher-quality query manipulation tools and better authentication services. LDAP proxy functionality will likely become a native function of directory service products and firewall proxies.
You need to consider several details of using LDAP proxy servers before you deploy such a solution. Although most vendors state that performance overhead is about 5 percent for query time, you also need to review the performance levels of the proxy server, in.cluding the number of queries that it can support. LDAP proxies offer little support for protocols other than LDAP. MLPS might use VBScript to support other protocols, but this would cause a problem with performance. Be aware that after you choose to use a LDAP proxy server, you'll have difficulty exchanging the server for another server that offers the same functionality. For example, MLPS uses VBScript to provide data transforms, but ILPS uses configuration files.
Ensure that you don't let an LDAP proxy implementation encourage you to maintain a flawed infrastructure. For support of a new application, LDAP proxy is easy to use to coalesce query results from several disparate directories. But in the long run, ensuring that your enterprise directory can support the application directly is better.
I recommend using the available LDAP proxy servers as a stopgap measure if your organization is on its way to a more complete directory-service de.ployment. Consider the available LDAP proxy servers for how they can speed up your deployment, not as a way to mitigate network limitations.
