Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
LDAP as a Naming Service
Designing a naming service based on existing industry standards presents its own set of challenges. Unlike NIS and NIS+, which were created for a specific purpose, directory servers are meant to be general purpose. While the flexibility they provide allows for a great deal of customization, there are a number of constraints imposed that are not present in proprietary (closed) implementations. The following paragraphs explain how the Solaris OE LDAP Client addresses the same issues presented in the previous section.
Where and how is data centrally stored?
LDAP data is stored in a complex structure defined by the directory server schema. To promote interoperability between LDAP implementations, schema definitions are often proposed in Request for Comments (RFCs) and adopted as standards. Object classes and attributes defined in the standard schema are assigned a unique identifier so they can be accessed by the same name no matter what implementation is deployed.
To map NIS and NIS+ data to an LDAP structure, the object classes and attributes defined in the RFC2307bis draft specification are used. For example, the posixAccount object class defines a structure to hold the fields present in passwd database entries. Likewise, the ipHost object class defines a structure to hold data from the hosts, ipnodes, and bootparams databases.
How can clients easily access the data?
Clients access the directory server through LDAP, which runs on top of Transmission Control Protocol/Internet Protocol (TCP/IP). Unlike NIS or NIS+, no remote procedure call (RPC) programs are required. The libraries that support LDAP functions are available on most any platform.
How can you eliminate single points of failure?
Directory servers have built-in replication facilities. Depending on the implementation, replication can be single- or multi-master. Single-master replication functions are similar to NIS and NIS+, allowing updates to be performed only on one server. Multi-master replication allows updates to be processed by more than one server. Only updates are propagated from a master to a replica, or a slave server. A change log on the master server maintains a record of all updates and is replayed through LDAP on the replicas to keep them synchronized.
Directory servers can also run in clusters to increase availability.
How can you prevent unauthorized access?
LDAP directory servers provide flexible mechanisms for both authentication and authorization. For clients to authenticate to a server, they must support the same authentication method. In other words, just because a server supports an authentication method, such as DIGEST-MD5, a client cannot automatically use it. The Sun_ ONE Directory Server 5.1 (formerly know as iPlanet_ Directory Server) supports the Simple Authentication and Security Layer (SASL) framework, which allows the server to negotiate authentication mechanisms if the other party also supports SASL.
Authorization, or the determination of what entries the user has access rights to, is set on the directory server. Anonymous access can be granted, or the user might be required to furnish some form of credentials before being authenticated. Once authenticated, access control lists (ACLs) are used to determine what level of permission to grant the user for particular entries, or groups of entries.
Proxy authentication allows operations to be performed on behalf of a user by a proxy user. This is a useful technique for allowing operations to be performed that the user normally would not have permission to perform.
How can you protect sensitive data from snooping?
Most directory servers provide a Secure Socket Layer (SSL) or Transport Layer Security (TLS) implementation that can be used for authentication and for data encryption. This is the same technology that is used to secure web transactions over the Internet. SSL/TLS can be configured so that the client trusts the server or the server trusts the client. As is the case with any authentication method, both client and server must support the same revision level of SSL/TLS to operate.
LDAP v3 compliant directory servers offer SSL/TLS through a protected port (636) or through the use of the Start TLS Extension (RFC 2830).
Does the naming service scale to an enterprise-wide level?
Directory servers, by nature, have the ability to handle very large databases. It is not uncommon to maintain a million or more entries in a single directory server. These servers are also optimized for fast read access and can support thousands of read requests per second on typical midrange servers. Data distribution over multiple servers is another way directory services can scale.
Directory server scaling is generally achieved by deploying replicated servers with load-balancing switches to direct LDAP requests from clients to them, and also increases the availability of the service.
Can it interoperate with other naming services?
Directory services can interoperate with other naming services that support LDAP v3. However, the way clients are required to authenticate to a naming service and how they gain authorization to network resources can be a limiting factor.