- Evolution of Solaris Naming Services
- NIS and Files Coexistence
- NIS and DNS Coexistence
- Solaris Naming Service Switch
- Solaris Naming Service Switch Architecture
- NIS Architecture Overview
- NIS Client Server Architecture
- How NIS Clients Bind to the NIS Server
- NIS Maps
- NIS High Availability Architecture Features
- NIS+ Architecture Overview
- NIS+ Client Server Architecture
- How NIS+ Clients Bind to the NIS+ Server
- NIS+ Tables
- NIS+ Interaction with DNS
- NIS+ High Availability Architecture Features
- Solaris DNS Architecture Overview
- DNS Client Architecture
- DNS Server Architecture
- DNS High Availability Features
- LDAP Architecture Overview
- LDAP Information Model
- LDAP Naming Model
- LDAP Functional Model
- LDAP Security Model
- LDAP Replication
- Comparison with Legacy Naming Services
This chapter is from the book
This chapter is from the book
This chapter is from the book
LDAP Information Model
The LDAP information model defines how entries in the directory are organized in the directory. Entries are arranged in a tree-like structure called the 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 may be several per DIT. Suffixes can be expressed as an organization (o=) or as an Internet style domain component (dc=). The LDAP predecessor, X.500, dictated a specific format which included a country, locality, and organization. These names were registered to avoid duplication. Since LDAP does not enforce the same stringent naming rules as X.500 any organization name can be specified. The domain-based format typically mirrors a company's DNS domain address and is expressed as domain component (dc) entries. Since most companies have a registered DNS name which ensures uniqueness, this format essentially replaces the old X.500 style format.
FIGURE 2-8 is an example of a DIT:
){kind=link}
FIGURE 2-8 Sample Directory Information Tree
Located below the suffix are organization unit (ou) entries. These entries can 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. You can use the same ou in a different portion of the DIT without creating a conflict. An ou entry called ou=People is created during the default iPlanet Directory Server installation; this entry is the default location for storing user account information, but any ou can be used for that purpose.
If you have 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, it can access the specified directory server.
Overall, the topology of the directory resembles that of a Solaris file system. It is a hierarchal structure which has containers (ou entries) where directory entries reside. Referrals are similar to NFS mount points in concept, though implemented differently. Unlike the naming convention of a file system, that of an LDAP directory is quite different and the entries stored are much more complex than those in Solaris files.