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.
End of Article
Register
