LDAP System Administration [Electronic resources] نسخه متنی

9.2 Directory Gateways

Gateways
are not a new concept; we've seen gateways between
different email formats, different network filesystems, and so on for
years. When building a gateway for directory services, one directory
protocol is used as the frontend (the
"face" presented to application
clients). Another protocol is used between the gateway and the
backend storage mechanism. The irony of using a directory gateway to
unify access to an LDAP server is that LDAP itself was originally
designed as a gateway protocol for X.500.

PADL's
ypldapdChapter 6, is an example of a gateway between NIS and
LDAP. Packages such as ypldapd tend to do one
thing and do it well. In many respects, such a gateway can simply be
viewed as another LDAP client. The gateway consumes LDAP information
and makes that information available to its clients through another
protocol.

Another example of an
NIS/LDAP gateway is the NIS service
distributed with Microsoft's
"Windows Services for
Unix (SFU)." This Active Directory add-on provides
tools for importing data from a NIS domain into Active Directory.
Once NIS data has been incorporated into Active Directory, SFU can provide services
for NIS clients from the Active Directory domain. For more
information on the SFU product, see http://www.microsoft.com/windows/sfu/.

The main advantage of using a gateway is that you usually
don't have to modify any clients. This alone can
save a great deal in the cost of administration. The disadvantage of
using a gateway is that translating requests and replies from one
protocol to the other requires additional overhead. Furthermore,
clients can't take full advantage of the LDAP
directory service; they're limited to the services
offered by the gateway. In many environments, these disadvantages are
relatively minor.