]> Symas Corp.

18740 Oxnard Street, Suite 313A Tarzana California 91356 USA +1 818 757-7087 hyc@symas.com

When both the LDAP client and server reside on the same machine, communication efficiency can be greatly improved using host- specific IPC mechanisms instead of a TCP session. Such mechanisms can also implicitly provide the client's identity to the server for extremely lightweight authentication. This document describes the implementation of LDAP over Unix IPC that has been in use in OpenLDAP since January 2000, including the URL format used to specify an IPC session.

While LDAP is a distributed access protocol, it is common for clients to be deployed on the same machine that hosts the server. Many applications are built on a tight integration of the client code and a co-resident server. In these tightly integrated deployments, where no actual network traffic is involved in the communication, the use of TCP/IP is overkill. Systems like Unix offer native IPC mechanisms that still provide the stream-oriented semantics of a TCP session, but with much greater efficiency. Since January 2000, OpenLDAP releases have provided the option to establish LDAP sessions over Unix Domain sockets as well as over TCP/IP. Such sessions are inherently as secure as TCP loopback sessions, but they consume fewer system resources, are much faster to establish and tear down, and they also provide secure identification of the client without requiring any additional passwords or other credentials.

Imperative keywords defined in are used in this document, and carry the meanings described there.

Many LDAP sessions consist of just one or two requests. Connection setup and teardown can become a significant portion of the time needed to process these sessions. Also under heavy load, the constraints of the 2MSL limit in TCP become a bottleneck. For example, a modest single processor dual-core AMD64 server running OpenLDAP can handle over 32,000 authentication requests per second on 100Mbps ethernet, with one connection per request. Connected over a host's loopback interface, the rate is much higher, but connections get completely throttled in under one second, because all of the host's port numbers have been used up and are in TIME_WAIT state. So even when the TCP processing overhead is insignificant, the constraints imposed in create an artificial limit on the server's performance. No such constraints exist when using IPC mechanisms instead of TCP.

The only change clients need to implement to use this feature is to use a special URL scheme instead of an ldap:// URL when specifying the target server. Likewise, the server needs to include this URL in the list of addresses on which it will listen.

The "ldapi:" URL scheme is used to denote an LDAP over IPC session. The address portion of the URL is the name of a Unix Domain socket, which is usually a fully qualified Unix filesystem pathname. Slashes in the pathname must be percent-encoded as described in section 2.1 of since they do not represent URL path delimiters in this usage. E.g., for a socket named "/var/run/ldapi" the server URL would be "ldapi://%26var%26run%26ldapi/". In all other respects, an ldapi URL conforms to . If no specific address is supplied, a default address MAY be used implicitly. In OpenLDAP the default address is a compile-time constant and its value is chosen by whoever built the software.

The basic transport uses a stream-oriented Unix Domain socket. The semantics of communication over such a socket are essentially identical to using a TCP session. Aside from the actual connection establishment, no special considerations are needed in the client, libraries, or server.

Since their introduction in 4.2 BSD Unix, Unix Domain sockets have also allowed passing credentials from one process to another. Modern systems may provide a server with easier means of obtaining the client's identity. The OpenLDAP implementation exploits multiple methods to acquire the client's identity. The discussion that follows is necessarily platform-specific. The OpenLDAP library provides a getpeereid() function to encapsulate all of the mechanisms used to acquire the identity. On FreeBSD and MacOSX the native getpeereid() is used. On modern Solaris systems the getpeerucred() system call is used. On systems like Linux that support the SO_PEERCRED option to getsockopt(), that option is used. On Unix systems lacking these explicit methods, descriptor passing is used. In this case, the client must send a message containing the descriptor as its very first action immediately after the socket is connected. The descriptor is attached to an LDAP Abandon Request with message ID zero, whose parameter is also message ID zero. This request is a pure no-op, and will be harmlessly ignored by any server that doesn't implement the protocol. For security reasons, the passed descriptor must be tightly controlled. The client creates a pipe and sends the pipe descriptor in the message. The server receives the descriptor and does an fstat() on it to determine the client's identity. The received descriptor MUST be a pipe, and its permission bits MUST only allow access to its owner. The owner uid and gid are then used as the client's identity. Note that these mechanisms are merely used to make the client's identity available to the server. The server will not actually use the identity information unless the client performs a SASL Bind using the EXTERNAL mechanism. I.e., as with any normal LDAP session, the session remains in the anonymous state until the client issues a Bind request.

It is possible to implement the corresponding functionality on Microsoft Windows-based systems using Named Pipes, but thus far there has been no demand for it, so the implementation has not been written. These are brief notes on the steps required for an implementation. The Pipe should be created in byte-read mode, and the client must specify SECURITY_IMPERSONATION access when it opens the pipe. The server can then retrieve the client's identity using the GetNamedPipeHandleState() function. Since Windows socket handles are not interchangeable with IPC handles, an alternate event handler would have to be provided instead of using Winsock's select() function.

This document describes a mechanism for accessing an LDAP server that is co-resident with the client machine. As such, it is inherently immune to security issues associated with using LDAP across a network. The mechanism also provides a means for a client to authenticate itself to the server without exposing any sensitive passwords. The security of this authentication is equal to the security of the host machine.

&rfc2119; &rfc2717; &rfc3986; &rfc4511; &rfc4513; &rfc4516; &rfc793;

This document satisfies the requirements of for registration of a new URL scheme.