Classnotes | LDAP01 | RecentChanges | Preferences 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, another 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.
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 another requires additional overhead. Furthermore, clients can't take full advantage oof the LDAP directory service; they are limitted to the services offered by the gateway.
PAM and LDAP
In chapter 6 of the book, they covered PADL's ypldapd daemon which was a gateway between NIS and LDAP. At the core of this daemon's functionality was an integration between PAM (Pluggable Authentication Modules) and LDAP.
In order to unify information between Microsoft's Active Directory, we need to employ this PAM-LDAP module.
The pam_ldap module provides the means for Unix and Linux workstations to authenticate against LDAP directories, and to change their passwords in the directory.
Key Benefits:
Uses the Pluggable Authentication Module API defined in OSF DCE RFC 86.0.
Can utilize transport layer security (such as SSL or TLS) to encrypt transactions between the workstation and the LDAP server and provide strongly authenticated sign-on.
Shares configuration information with nss_ldap module
Supports ypldapd locator for finding LDAP servers
Supports Netscape Directory Server's password policies and directory-based access authorization.
