LDAP in the Solaris Operating Environment[c] Deploying Secure Directory Services
| Readers who are new to LDAP technology might find some of the terminology confusing. In this section, common terms are defined in the context of LDAP services in the Solaris OE. Directory Service versus Naming Service
The terms directory service and naming service are often used interchangeably. In a strict sense, a directory service implies that data is stored in a sophisticated structure, while a naming service generally uses a simpler data structure such as a two column table. LDAP Server versus Directory Server
Often a directory server is mistakenly referred to as an LDAP server because the directory server uses LDAP technology to access information. In this book, the term directory server is used instead of LDAP server, not to be pedantic, but because there is a real difference between the two. While file servers can be called NFS or SMB servers because of the underlying protocol they use, LDAP is more of an interface that a server uses than a specification of what the server is. A directory server refers to a product or a specific implementation that uses LDAP technology. While there are many directory servers out there, the one most referenced in this book is the Sun ONE Directory Server 5.2 software. LDAP Models
LDAP is defined by the four models it supports as follows :
The following sections describe these models and how they are used in this book. Information Model
Entries are arranged in a tree-like structure (FIGURE 1-1) called the directory information tree (DIT). Figure 1-1. Sample Directory Information Tree (DIT)
At the top of the DIT is the directory root, which is identified by the server name and port number on which the directory service is running. Multiple instances of the directory service can be running on the same server, with each instance having its own DIT. Below the directory root is the directory suffix, of which there can be several for each DIT. Suffixes can be expressed as an organization ( o= ) or as an Internet-style domain component ( dc= ). The domain-based format typically mirrors a company's DNS domain address and is expressed as domain component ( dc ) entries. Located below the suffix are organization unit ( ou ) entries. These entries can be nested, so an ou can contain other organization units. The name chosen for an ou only needs to be unique at the level at which it resides. The same ou can be used in a different portion of the DIT without creating a conflict. An ou entry called ou=people is created during the default Directory Server installation. This entry is the default location for storing user account information, but any ou can be used for that purpose. If there are multiple directory servers in a network, they can be linked by LDAP referrals. A referral is a mechanism that instructs an LDAP client searching the directory to continue the search on another directory server. The referral accomplishes this instruction by passing a Uniform Resource Locator (URL) back to the client. Once the client receives the URL, the client can access the specified directory server. Naming Model
LDAP is flexible, but at the same time provides enough structure that LDAP clients can access data in any LDAP-compliant directory. For comparison purposes, an LDAP directory is unlike a Solaris OE file system, where a search can always be initiated from the root file system ( / ). Instead, an LDAP directory search begins by specifying one specific entry, such as dc=blueprints, dc=com , as a search base. The entry name is specified as a distinguished name (DN), which is a series of relative distinguished names (RDNs). Each directory server contains a single root directory-specific entry (DSE) which contains basic information about the LDAP server. The DSE contains a list of suffixes supported by the directory server. This entry can be read to determine what suffixes are present, and in turn , those suffixes can be searched. Functional Model
Clients that need to access data on an LDAP server first perform a bind operation. The act of binding to the directory is analogous to logging in to a system. The bind operation requires, at a minimum, the DN of the user account entry with which the client wishes to bind. If the entry has a password, then, depending on the authentication method, the password is passed along with the DN. Alternatively, the client can perform an anonymous bind, which does not require a particular user name or password. The bind operation specifies the type of authentication it is attempting to perform. The authentication method the client specifies must be supported by the directory server. The Simple Authentication and Security Level (SASL) interface provides a mechanism for deploying authentication methods that are not directory server specific. The DSE exposes a list of supported SASL mechanisms. The default is Simple authentication, which compares the password sent with the password stored for the specified DN. Because the Simple authentication method sends a clear text password, it is not secure unless combined with Transport Layer Security (TLS), such as SSL. However, other authentication methods (for example, DIGEST-MD5) work securely even without the use of TLS. If the bind operation is successful, the client is considered authenticated. All subsequent client requests made on the established connection as a result of the bind are performed as the authenticated user. After the LDAP client requests are complete, an unbind operation is performed to release the connection. Security Model
Access to LDAP entries on the server is protected by the rights established for the authenticated user. The rights can be assigned at the container, object, or attribute level. A portion of the DIT can be assigned stricter (or looser) control than other parts of the DIT. All entries of the same object class type can be assigned the same control. Control can also be established at the attribute level to protect certain information. For example, an employee's password might have restricted access, while other information is available to everyone. The mechanism used to assign access rights is called the access control instruction (ACI). A single ACI can protect the entire DIT, or several can be used to provide finer-grained protection. When multiple ACIs are created, the ACIs that deny access take precedence. For example, if access is granted to everyone at the top level of the DIT but denied access to ou=Contractors , then the permission set for ou=Contractors is enforced. ACIs are hierarchal. That is, an ACI set at any node of a DIT affects everything below it. Therefore you need to be aware of ACIs that may be set above the node or entry you are protecting. Directory Objects and Attributes
The structure of a directory entry is defined by the object class to which it belongs. An object class defines a set of attributes that can be stored in a directory entry. LDAP object classes are extensible by creation of a new class that is a child of an existing one. All the attributes defined in the parent class are inherited by the child. The name of an object class must be unique within the directory server and can be registered as a standard LDAP object. These objects are assigned a numeric object identifier (OID) to ensure they will not conflict with another object class. Attribute names are unique within the directory server and can be contained in more than one object class. The type of data that can be stored in an attribute and the way a search for data is handled is well defined. For example, searching for a string-valued attribute can be case sensitive or insensitive. Attributes can also contain more than one value and can have aliases. To promote interoperability, a set of standard LDAP object classes and attributes have been defined. Definitions of these ship with most LDAP servers in the form of schema configuration files. If they do not exist on a server, you can add the content of these schema files to the LDAP configuration files. Directory Schema
The information specified in a directory schema includes the object class name, required and allowed attributes, an OID number, and the allowable syntax. The following table shows the schema definition for the posixAccount object class attributes that stores Solaris OE user account information. Table 1-1. posixAccount object Class Schema Definition
In this example, cn is a case-insensitive string that can contain multiple values. The gidNumber and uidNumber are integers, and homePhone is represented by a special data type used for telephone numbers . The loginShell is represented by a case-exact string. Note that the LDAP uid , which is a string, is not the same as the numeric Solaris OE UID, which is represented by the LDAP attribute uidNumber . Distinguished Names (DN)
A directory entry is identified by its DN, which is similar to a file system path name. Entries are composed of many attributes, some of which are the same as other entries. To distinguish between entries that may have the same values for some attributes, one attribute is usually singled out as being unique. For user account entries defined in the posixAccount object class, the unique attribute is uid . To prevent duplicate values from being used, the Sun ONE Directory Server software is configured by default to enforce uid attribute uniqueness. Entries that do not have a uid attribute are typically identified by the commonName ( cn ) attribute, which is available in most object classes, but is not required by all object classes such as organization ( o ) and organization unit ( ou ). The form of a DN is as follows: attribute=value,container,suffix There can be multiple containers depending on the DIT topology. The following is an example of a DN for a user account: uid=cathy,ou=People,dc=example,dc=com The RDN specifies the left-most portion of the DN, which uniquely identifies the entry relative to its parent. For example: uid=cathy In this case, uid=cathy has to be unique within the ou=People container. Replication
Replication is the mechanism by which directory data is automatically copied from one directory server to another. Servers that can be updated are called master servers or master replicas and servers that cannot are called read-only replicas . The directory server that provides the data to other servers is called the supplier server . Servers that accept data from suppliers are called consumers . A directory server can be both a consumer and a supplier server. That is, it can receive updates from one server, then pass them on to one or more others. The Sun ONE 5.2 Directory Server software supports three kinds of replication topologies:
Solaris OE LDAP Client
The term LDAP client has two connotations . In the traditional sense, any client that can perform LDAP operations is an LDAP client. This can be an LDAP-enabled browser like Netscape Communicator, or an operating environment that contains commands that are written to the LDAP API. The Solaris OE provides an LDAP API (see ldap(3LDAP) ), and a number of tools, including ldapsearch(1) , ldapadd(1) , ldapdelete (1) , ldapmodify (1) , and ldapmodrdn (1) that are built directly on top of the API. Another use of the term LDAP client is to identify a Solaris OE client that accesses an LDAP directory for its naming service data. The first generation of this client appeared in the Solaris 8 OE. This client is referred to as the Native LDAP Client . The second generation of the client appeared in Solaris 9 OE, and was later backported to Solaris 8 OE. This LDAP client is referred to as the Secured LDAP Client . In general, when the term LDAP client is used in this book, it refers to the Secured LDAP Client implementation. |